OpenSSH Certkey (PKI)

Bob Beck beck at bofh.cns.ualberta.ca
Thu Nov 16 12:49:24 PST 2006



	I would think it would be nice if "CAL" had a way of
saying "these are the ones to be revoked" so no shutdown, just
propagate the bad one - but I'm talking to daniel offline about it..


* Nick Bender <nbender at gmail.com> [2006-11-16 13:23]:
> >+SECURITY IMPLICATIONS
> >+
> >+The CA, specifically the holder of the CA private key (and its password, 
> >if it
> >+is password encrypted), holds broad control over hosts and user accounts 
> >set
> >+up in this way. Should the CA private key become compromised, all user
> >+accounts become compromised.
> >+
> >+There is no way to revoke a certificate once it has been published, the
> >+certificate is valid until it reaches the expiry date set by the CA.
> >+
> 
> After spending a good part of a night locking down a network when an
> admin "left" this leaves me feeling cold.
> 
> I think the addition of CAL gives you at least a prayer of addressing
> this in a timely manner. In the event that you need to reauthorize
> from the top:
> 
> 1. Shutdown your CAL servers.
> 2. Generate and distribute new CA cert.
> 3. Generate and distribute new host certs.
> 4. Startup CAL servers.
> 5. Generate and distribute new user certs.
> 
> Did I miss anything?
> 
> The vulnerability window is now time from compromise to time of shutdown
> of CAL servers.
> 
> Note that there is one other time where the same procedure is required
> but without the time pressure - at CA cert expiry time.
> 
> I think the procedure should at least be included in the documentation
> if not supported in some way by software...
> 
> -N
> 

-- 
#!/usr/bin/perl
if ((not 0 && not 1) !=  (! 0 && ! 1)) {
   print "Larry and Tom must smoke some really primo stuff...\n"; 
}


More information about the freebsd-current mailing list