Re: OpenSSH key blacklisting

[Nathanael Hoyle <nhoyle () hoyletech com>]

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