Date: Wed, 04 Jun 2008 11:14:12 -0400 From: Nathanael Hoyle <nhoyle@...letech.com> To: oss-security@...ts.openwall.com Subject: Re: OpenSSH key blacklisting Tim Brown wrote: > Answering comments in line as applicable... Alright, doing same... > <snip> > > On Wednesday 28 May 2008 15:43:39 Nathanael Hoyle wrote: > >> 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. > > The idea of CAs as a revenue generating model is IMO, something akin to snake > oil. To clarify, do you mean that the business model of commercial CAs is that of snake oil vendors, or that my statement, which implies that CAs necessarily be commercial is snake oil? I realize that not all CAs are commercial, but there are very few non-commercial ones which are well-recognized and whom could reasonably (IMO) be expected to have no interest/bias beyond ensuring that their key issuance product was solid. Certaily non-profit and private CAs exist and still provide value in > certifying individuals and hosts. Why for example, could some way not be > found to make it easier for host keys generated by a particular > version/package of ssh-keygen to be revoked rather than employing the > blacklist solution currently on the table. Moreover, why couldn't such a > solution allow for alternative revocation source. A typical public key looks something like: id-rsa really-long-string-of-base64-encoded-key-here hostname Note that there is not a 'signature' from the version of ssh-keygen which created this key. I do not see any method of determining this information client-side when presented with a key upon connection. In the absence of this meta-information being available to the remote client, it cannot be used as the basis for revocation or acceptance. This is the sort of thing which could be addressed through an extension to the current RFC to mandate a comment or header field in both the keyfile and the client negotiation protocol which indicated the specific package and revision which generated the key. Obviously, in order for this to be useful, the RFC would have to mandate a standardized format for version strings so that they could be readily compared (i.e. versions <= X are known to be vulnerable). The concern introduced by such a mechanism is information disclosure. If I were acting the role of the script kiddie, a host becomes MUCH more interesting if it's client negotiation reveals that it's key-pair was generated using a known-vulnerable package revision. This could clue me in to the fact that a host had the reduced-keyspace issue like the recent debian one, or a similar one which would allow me to concentrate and focus my attack. That's bad news. It is probably sufficiently bad news as to bar adoption of such a mechanism. Note that putting a revision stamp in a keyfile could still allow an administrator to check hosts on his/her network to look for potentially compromised keys, without disclosing the information via the network protocol. Of course that means it is useless to the client. As to the second half of your question, about revocation source, I believe it makes good sense for the party which issued the ssh package and digitally signed it to be able to 'revoke' the package as insecure. For any other party to be authorized to do this, returns to the issue of a central CA. In such a circumstance, > the ssh client could be configured (at both a host and user level) to support > both warning and/or preventing connections to hosts with revoked keys. > > *snip* > >> 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. > > Exactly, and the blacklist solution fails to adequately address these use > cases. In the general case, certainly. In the specific case, revoking each of the possibly generated keys from the reduced seed space does address the case-in-point issue. > >> 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? > > Surely, the owner of the system and the owner of the client should both be > able to make such choices by the configurations they apply to their systems. I wish that I could agree completely with you here, but I don't. In an 'ideal' world, absolutely. Probably those who are actively interested in auditing and maintaining the security of their systems could do so readily. That fact may be sufficient to drive the implementation of such an 'optional' extension. However, the reason debian got into the mess they did in the first place with this was specifically because they were trying to remove responsibility from the can't-be-bothered users for configuration. At one point, nearly all ssh key generation systems required the user the type keys 'at random' on the keyboard, and/or to move the mouse to generate an entropy pool for a seed value for key generation. Because debian performs key-generation on first boot in most cases, that early in the startup there might not be sufficient entropy in the network traffic for utility. I guess they found that users were either incapable of or disinclined to participate in the key generation process. These same users would not participate in configuring trusted certifying/revoking authorities for keypairs either. Thus the question becomes one of sufficiently acceptable default values for a distro vendor to pre-set. I am hard pressed to think of external non-commercial entities which could be entrusted with this task reliably enough that I would want to make them the default in a distro I packaged. I would welcome thoughts on that. > >> 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. > > As I say, the owner of the system and the owner of the client should both be > able to configure their own components. Therefore they would be in a > position to make their own judgements on the trustworthiness or otherwise of > a particular CA. Much as already happens with for example DNS blackholes for > mail. > The DNS blackholes for email is a very interesting case for comparison purposes. I find such to be indispensable for managing/controlling spam on an email network. As an implementation, this makes good sense. As per my above comments however, I fear that the benefits of such an implementation could be limited to the users who knew/cared and that this would not readily be pre-packageable for the masses. >> It's definitely a question worth pursuing, but I don't think it will be >> particularly trivial to solve across the community. > > I don't doubt it, but if noone poses the question, we'll never find out if > there is anyone smart enough to solve it. As such, I leave it for the reader > to figure out if the problem has a solution. Agreed. > > Tim -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.