[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200806030038.00102.tmb@65535.com>
Date: Tue, 3 Jun 2008 00:37:59 +0100
From: Tim Brown <tmb@...35.com>
To: oss-security@...ts.openwall.com
Subject: Re: OpenSSH key blacklisting
Answering comments in line as applicable...
On Wednesday 28 May 2008 15:26:07 Sebastian Krahmer wrote:
> Last time I looked at the drafts (now RFC) there was no
> spec for revoking user-keys. However it allows x509
> certificates for hostkeys.
> Its all about the RFCs. OpenSSH folks shouldnt implement
> proprietary stuff :)
AFAIK, SSH wasn't born of RFCs but rather the RFCs were born from an
implementation. That being said, I don't consider an open source
implementation (of a new standard) to be proprietry but rather a reference
implementation which others can choose to follow (or not). Others may beg to
differ. Moreover does the blacklist solution not count as a proprietry
solution by the standards you suggest?
> At the end of the day SSH is not really a PKI system. The focus
> has been on different issues.
True, but my argument is as to whether such focus is appropriate.
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. 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. 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.
> 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.
> 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.
> 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.
Tim
--
Tim Brown
<mailto:tmb@...35.com>
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.
