OpenSSH PKI [was: Re: Call for testing: OpenSSH-5.4]

[Damien Miller]

On Sat, 27 Feb 2010, Daniel Kahn Gillmor wrote:

> Hi Damien--
> 
> On 02/27/2010 02:25 AM, Damien Miller wrote:
> > OpenSSH 5.4 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This is a big release,
> > with a number of major new features and many bug fixes.
> 
> This is exciting news, thanks!
> 
> As a contributor to the Monkeysphere (OpenPGP certificates for SSH and
> TLS [0]), i'm particularly interested in this bit:
> 
> >  * Add support for certificate authentication of users and hosts using a
> >    new, minimal OpenSSH certificate format (not X.509). Certificates
> >    contain a public key, identity information and some validity
> >    constraints and are signed with a standard SSH public key using
> >    ssh-keygen(1). CA keys may be marked as trusted in authorized_keys
> >    (for user authentication) or known_hosts (for host authentication).
> > 
> >    Documentation for certificate support may be found in ssh-keygen(1),
> >    sshd(8) and ssh(1) and a description of the protocol changes in
> >    PROTOCOL.certkeys.
> 
> My initial reaction is surprise -- i had no idea that this was in the
> works.  Where would i have found out that this was being proposed if i
> wanted to contribute to the work here?  I don't see any mention of it in
> the bug tracker, and if there was discussion about it on this list then
> i missed it somehow.  Should i be subscribed to some other discussion
> list to get a heads-up about this sort of thing?  Is there something
> else i should follow?

No, I discussed it privately with the other OpenSSH developers at the
OpenBSD network hackathon a month ago and ran it past some of the
cryptographers who are still speaking to me.

> I have some concerns about the model and the implementation, based on
> what i've read from PROTOCOL.certkeys and the various referenced man
> pages in cvs HEAD:
> 
>  0) Yet another certificate format, introducing a novel PKI -- seems
> like this opens the door to a lot of potential trouble.  Simplicity is a
> good reason to avoid PKI entirely, and OpenSSH has done right by this
> model so far.  But the PKI-less model has its limitations, and when the
> need for a PKI seems apparent, there are at least two well-known PKIs
> (OpenPGP and X.509) with decent communities who can contribute insights
> on what might work and what might cause trouble down the line.  The
> model proposed here is simpler than either existing PKI, but it also
> seems to have had far less scrutiny, and is OpenSSH-specific, as far as
> i can tell.  OpenSSH doesn't rely on novel/unique asymmetric crypto
> algorithms, symmetric ciphers, or message digests.  Why should
> certificate formats and PKI be different?

I think the PROTOCOL.certkeys explains that already: these certificates
are intended to be _very_ simple and add little attack surface to
OpenSSH's critical preauth phase. They use the same wire encoding and
the same signature algorithms and representation as traditional SSH 
public key authentication.

Both OpenPGP and X.509 are way more complex. OpenPGP has IIRC four ways
just to encode a length field and ASN.1 is much worse still. Apart
from the encoding complexity, the semantics of authorization using
X.509 and, particularly, OpenPGP are more complicated too.

>  1) Revocations -- there is no room in the infrastructure i can see for
> revocations.  What should a certificate authority do if it discovers
> that the private key belonging to a certificate has been compromised,
> and the certificate is not yet expired?  What should a server operator
> do who knows this situation, but currently relies on other
> certifications from that CA?

Revocation is planned to be implemented as a simple file containing a list
of banned keys.

>  2) Tight coupling of authentication and authorization -- there are
> sometimes good reasons to do this, but it makes certification more
> difficult, and makes policy much more inflexible for system
> administrators.  One example of the added complexity the conflation
> creates is a combinatoric one: say i should be allowed to ssh to
> dkg at example.com to do whatever i want with my account.  But i should
> *also* be allowed access to our organization's SVN repository over ssh
> at svn at example.com constrained by a ForceCommand that only allows
> certain subversion operations.  i don't think that's representable in
> this certificate format.   More generally, a local machine administrator
> might be fine relying on an external authority to identify remote
> parties, but might want to authorize different commands for local
> accounts based on that authentication.  Having this tightly coupled
> model means those local administrators must either accept authorization
> information from the CAs, or not use certificates at all.

That's sort of the point - the CA is trusted to set authorisation policy
for the administrative domain defined by the set of hosts that trust its
key. This is fully optional too - all the authorized_keys and sshd_config
authorization options apply too, so no functionality is lost if the CA
wants to be authentication only.

>  3) Multiple certs over the same key from different issuers -- Say i use
> the same key to identify myself to machines from multiple domains.  if
> each of those domains runs their own internal certificate authority,
> i'll have two different versions of id_rsa_cert.pub, right?  i see no
> documentation to indicate how to choose between them in ssh(1) or
> ssh_config(5).

I won't say that I have gone out of my way to make this difficult, but
it doesn't make me sad that the human interface discourages key sharing
between different trust domains.

>  4) definition of "valid principals" seems underdeveloped in
> PROTOCOL.certkeys -- For example, there was discussion on-list recently
> about case insensitivity on some systems (cygwin at least) -- are these
> expected to match the name of the remote account entirely?

yes.

>  If i certify
> a key for "foo" does that work on all "foo" accounts on every machine
> that trusts my CA?

yes. Remember that CA keys can be trusted on an account by account basis,
so if there are subsets of hosts within a domain that use a different
naming scheme then the users who trust the CA for login can be subsetted.

I'm planning to add a sshd-wide (well, Match block wide) way to specify
trusted CA keys too.

>  Can user accounts be specified targetted to a
> specific machine (e.g. "foo at server3.example.net")?  if so, how would
> sshd make authorization decisions based on the hostname part of the user
> name?

The certificate format is extensible. I considered a
SSH2_CERT_TYPE_USER_HOST certificate type, but punted on it for the initial
revision precisely because I wasn't clear what semantics should be used
to define the hostname and whether or not to include wildcards. Hosts
on which a cert is valid could also be expressed as a certificate 
constraint, I'm not sure which is nicer.

>  5) interaction with ssh-agent -- does the agent know about
> certificates?  Can it offer them to a compatible ssh client process?  If
> not, how should a user take advantage of both features?  If so, is this
> a change in the ssh-agent protocol that compatible ssh-agent
> implementations should be made aware of?

Yes, it will try to load the corresponding *-cert.pub files and should
send them, just like other keys.

> Anyway, these are my immediate reactions to this proposal of new
> certificate formats for OpenSSH.  My current thinking is that this
> particular change should be pushed back to a later version for more
> discussion, but of course that's not my call to make.

I don't think there is any reason to remove it. If people don't like
it they can not switch it on. The certificate format is extensible, and
several of the things that you asked for above could be accomodated
using the extension mechanisms already present (even without touching
the "reserved" field in the cert).

-d