Date: Wed, 28 May 2008 10:43:39 -0400 From: Nathanael Hoyle <nhoyle@...letech.com> To: oss-security@...ts.openwall.com Subject: Re: OpenSSH key blacklisting Tim Brown wrote: > All, > > Maybe I've missed something, in which case, shoot me down, but why unlike > other services that make use of public key cryptography, does OpenSSH not > have use a model which supports proper authorisation and revocation > mechanisms? Would this not be an ideal opportunity to implement this? > Whilst I think there was a reasonable case for such features prior to the > Debian OpenSSL vulnerability being identified, I would argue that this issue > highlights the case. Comercial SSH already has such functionality - can > anyone offer a view on how [well] it works? > > Tim My first thought here has to do with the issues involved in key management. I'm not sure that a certifying/key-issuing central ($$$) authority with the ability to do revocations is the right model for most OSS users. Think SSL certificates and Verisign... I believe many OSS projects would not wish to incur this expense. Then you have self-signed certificates (and/or self-generated key pairs) and PGP/GPG-style web of trust things... all quite complicated and somewhat questionable. Obviously, there has to be a way to invalidate a key. Doing it in a non-standardized way in the common implementation (openssh) isn't ideal. Using a 16-bit seed to generate a much longer key (the debian PID usage) is a great example of what happens when you try to automate/simplify certain things for the users (practically all distributions used to ask you to press letters on the keyboard and move the mouse to create an entropy pool...) in a way that invalidates the premise of the security model (a highly random seed value). The specific case is somewhat unusual, because it is not an instance where a single host/site needed to revoke a previously valid key because of compromise (although that case is not properly addressed, currently), but one where many hosts, including those to which one has never before connected, might have keys which fall within the predictable space, and therefore be effectively compromised. It is interesting to note that a typical 'web-of-trust' implementation would not properly handle this type of situation in a reliable manner, highlighting the need for a central key authority. The question then becomes, who in the OSS community would be considered a universally trusted entity to perform key registration and revocation for SSH key pairs, and how is such an entity funded? Also, how does on resolve the apparent privacy concerns over querying such a central repository with a public key signature to check for revocation prior to usage? For my own purposes, I would not want to pass the key in question along... which means that perhaps an rsync-style source which could be synchronized to a local revoked key list is the proper implementation, avoiding disclosing which keys you were specifically interested in to the central key authority. It's definitely a question worth pursuing, but I don't think it will be particularly trivial to solve across the community. -Nathanael
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.