Date: Wed, 15 Nov 2006 10:47:47 -0700 From: Bob Beck <beck@bofh.cns.ualberta.ca> To: Andre Oppermann <andre@freebsd.org> Cc: Daniel Hartmeier <daniel@benzedrine.cx>, tech@openbsd.org, openssh-unix-dev@mindrot.org, markus@openbsd.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) Message-ID: <20061115174747.GE26418@bofh.cns.ualberta.ca> In-Reply-To: <455B29A4.3000601@freebsd.org> References: <20061115142820.GB14649@insomnia.benzedrine.cx> <455B29A4.3000601@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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" > > 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. 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. 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. (Now I'll go away and be cranky elsewhere, having a bad day) -Bob
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061115174747.GE26418>