Re: OpenSSH Certkey (PKI)

Bob Beck wrote:
> 	Sigh. My objections to this are my objections to PKI implementations
> in general.  In my experience PKI methods are implemented and deployed
> the same way people deploy half done raid drivers - we'll make the
> disk work, but we won't worry about how to monitor and fix it when it
> gets fucked up.  "that'll be implemented later/left as an exercise for
> the deployer to hack up something disgusting"

Well, we post these patches to solicit valuable input and to refine it
based on all the smart brains choosing to care.

In our primary application we exactly want offline mode (the ability to
login even if half or most of the network is down).  We actually are the
network we want to bring up again.  Here we had to make a tradeoff and
traded the ability to revoke a certificate against not being able to
recover the network.  Yeah, this is an easy one to make. ;-)

Nonetheless we want to feed back a useful solution to the community and
I've assigned some more developer time (Daniel Hartmeier) to address your
concerns.

>>  b) It adds a certificate to the public key of a ssh user so the ssh
>>  server can verify the authenticity of a users pubkey without having
>>  to have a pre-populated authorized_keys file in each users home
>>  directory on all machines this user has access to.
>>  keys and authorized keys files).
> 
> 	I maintain it does NOT do this - and here is why :
> 
>>  Less severe incidents include lost or compromised user keys.  OpenSSH
>>  PKI gives two methods to deal with this.  First it allows to specify
>>  an expiry date for all certificates.  If set sufficiently short all
>>  certs lose their usefulness quickly.  All users have to be re-certified
>>  in intervals and the re-certification can be tied to any number of
>>  administrative criteria.  For immediate reactions any number of public
>>  key fingerprints can be blacklisted on the ssh server.  This is a simple
>>  file based certificate revocation.  Online revocation checks could
>>  optionally be implemented as well.  The operator then has to specify
>>  whether to fail open or close depending on priorities and risk
>>  assessments.
> 
> 	In other words, I have to maintain a pre-populated "un-authorized"
> keys file  because in any real deployment you are GOING to have these. 
> and quite frequently with any sizable deployment. So I still have
> to maintain a file. 
> 
> 	"authorized keys" -> anything that is not allowed is denied. 
> 	"un-authorized keys" -> anything that is not denied is allowed.
> 
> 	NOT being prepared to maintain a file when doing this
> is pretty much akin to "Don't worry, I'll pull out before I cum". Everything's
> great until there a problem and then it's a fuckshow.  

Well, step 1 is to have something that is better than reality shows
today while requiring the same effort or dealing with the same laziness.
There are way too many people out there who handle the security OpenSSH
could provide in a very ineffective and dangerous way.  If we can lift
them up to the next practical security level while maintaining the same
ease of use (or inappropriate practices) and laziness I call it a first
success.

Step 2 is to make the theoretical perfect security a reality by maintaining
(almost) the same ease of use and laziness on part of the user.  For the
administrator it must mean only a very slight increase in inconvenience
and effort with the clear payoff of much increased security.

Step 1 we IMHO have mastered.  Lets work on Step 2.  See below.

> 	I.E. this is the same "it's really cool and we almost have it right"
> argument I've seen from everything pushing PKI and x509 goo as
> authentication. An expiry date for all the user certs? gimme a break.
> even setting it to a month (which would be a pita to have users
> constantly re-certed) means someone gets a month to fuck around. Even
> suggesting that certificate expiry times should be used to mitigate
> this is irresponsible. You have to be able to nail something you know
> is compromised quickly. The only thing expiry times to is A) make
> money for commercial CA's, B) make stuff not have to stay forever in
> your CRL if you have one. 

The latter is our main motivator. ;-)

> 	Don't get me wrong, I think this is possibly useful, but I don't
> think it should go in incomplete like this. In my view it is complete
> where when turning it on you specify a set of (possibly other) ssh
> server(s) the server itself will connect to and use as a CRL when
> presented with a key. - i.e. we should make it decently doable and
> document how to use a CRL in this case. I feel quite strongly that
> without tying the last piece together, we're handing people an
> incomplete thing with enough rope to hang themselves - "Here's a nice
> thing for a centralized deployment but oops if a luser loses a key you
> have to run around and do a panty raid to all your servers, because we
> left that as an exercise just like every other fucktard that
> implements this stuff does instead of giving you the tools to do it
> right"
> 
> 	So, My two cents, make it complete first. Making an archetecture
> for ssh that makes it easy to add trust centrally WITHOUT MAKING IT EASY
> TO REMOVE IT is irresponsible.

Ok, I've devised a way to easily configure and run a secure CAL
(Certificate Authorization List) that can just as easily be distributed
to multiple redundant CAL Servers.  We'll implement it tomorrow (after
some internal discussion with claudio&dhartmei) and post it here for
review as an updated OpenSSH PKI patch.

-- 
Andre