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

[Daniel Kahn Gillmor]

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?

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?

 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?

 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.

 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).

 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?  If i certify
a key for "foo" does that work on all "foo" accounts on every machine
that trusts my CA?  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?

 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?

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'd appreciate any feedback on the thoughts and concerns raised above.

As always, thanks for all the work on this excellent tool.

Regards,

	--dkg

[0] http://web.monkeysphere.info/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20100227/0eb768a6/attachment-0001.bin>