Subject: OpenSSH certified keys

From: Damien Miller <[email-masked]>
Date: Wed, 17 Mar 2010 04:19:28 +1100 (EST)

Hi,

OpenSSH 5.4p1 introduced a novel, lightweight certificate format for
user and host keys. These were designed to reuse SSH wire-encoding and
signature primitives to minimise the additional attack surface exposed
pre-auth. In particular, we are not comfortable with the complexity
(syntactically or sematically) of X.509.

Here is the document from the OpenSSH source distribution that describes
them (PROTOCOL.certkeys). If there is interested from other implementors
in interoperating with these certificates then I'm willing to write this
up as an I-D.

-d

------------------------

This document describes a simple public-key certificate authentication
system for use by SSH.

Background
----------

The SSH protocol currently supports a simple public key authentication
mechanism. Unlike other public key implementations, SSH eschews the
use of X.509 certificates and uses raw keys. This approach has some
benefits relating to simplicity of configuration and minimisation
of attack surface, but it does not support the important use-cases
of centrally managed, passwordless authentication and centrally
certified host keys.

These protocol extensions build on the simple public key authentication
system already in SSH to allow certificate-based authentication.
The certificates used are not traditional X.509 certificates, with
numerous options and complex encoding rules, but something rather
more minimal: a key, some identity information and usage constraints
that have been signed with some other trusted key.

A sshd server may be configured to allow authentication via certified
keys, by extending the existing ~/.ssh/authorized_keys mechanism
to allow specification of certification authority keys in addition
to raw user keys. The ssh client will support automatic verification
of acceptance of certified host keys, by adding a similar ability
to specify CA keys in ~/.ssh/known_hosts.

Certified keys are represented using two new key types:
[email-masked] and [email-masked] that
include certification information along with the public key that is used
to sign challenges. ssh-keygen performs the CA signing operation.

Protocol extensions
-------------------

The SSH wire protocol includes several extensibility mechanisms.
These modifications shall take advantage of namespaced public key
algorithm names to add support for certificate authentication without
breaking the protocol - implementations that do not support the
extensions will simply ignore them.

Authentication using the new key formats described below proceeds
using the existing SSH "publickey" authentication method described
in RFC4252 section 7.

New public key formats
----------------------

The [email-masked] and [email-masked] key
types take a similar high-level format (note: data types and
encoding are as per RFC4251 section 5). The serialised wire encoding of
these certificates is also used for storing them on disk.

#define SSH_CERT_TYPE_USER    1
#define SSH_CERT_TYPE_HOST    2

RSA certificate

    string    "[email-masked]"
    mpint     e
    mpint     n
    uint32    type
    string    key id
    string    valid principals
    uint64    valid after
    uint64    valid before
    string    constraints
    string    nonce
    string    reserved
    string    signature key
    string    signature

DSA certificate

    string    "[email-masked]"
    mpint     p
    mpint     q
    mpint     g
    mpint     y
    uint32    type
    string    key id
    string    valid principals
    uint64    valid after
    uint64    valid before
    string    constraints
    string    nonce
    string    reserved
    string    signature key
    string    signature

e and n are the RSA exponent and public modulus respectively.

p, q, g, y are the DSA parameters as described in FIPS-186-2.

type specifies whether this certificate is for identification of a user
or a host using a SSH_CERT_TYPE_... value.

key id is a free-form text field that is filled in by the CA at the time
of signing; the intention is that the contents of this field are used to
identify the identity principal in log messages.

"valid principals" is a string containing zero or more principals as
strings packed inside it. These principals list the names for which this
certificate is valid; hostnames for SSH_CERT_TYPE_HOST certificates and
usernames for SSH_CERT_TYPE_USER certificates. As a special case, a
zero-length "valid principals" field means the certificate is valid for
any principal of the specified type. XXX DNS wildcards?

"valid after" and "valid before" specify a validity period for the
certificate. Each represents a time in seconds since 1970-01-01
00:00:00. A certificate is considered valid if:
	 valid after <= current time < valid before

constraints is a set of zero or more key constraints encoded as below.

The nonce field is a CA-provided random bitstring of arbitrary length
(but typically 16 or 32 bytes) included to make attacks that depend on
inducing collisions in the signature hash infeasible.

The reserved field is current unused and is ignored in this version of
the protocol.

signature key contains the CA key used to sign the certificate.
The valid key types for CA keys are ssh-rsa and ssh-dss. "Chained"
certificates, where the signature key type is a certificate type itself
are NOT supported. Note that it is possible for a RSA certificate key to
be signed by a DSS CA key and vice-versa.

signature is computed over all preceding fields from the initial string
up to, and including the signature key. Signatures are computed and
encoded according to the rules defined for the CA's public key algorithm
(RFC4253 section 6.6 for ssh-rsa and ssh-dss).

Constraints
-----------

The constraints section of the certificate specifies zero or more
constraints on the certificates validity. The format of this field
is a sequence of zero or more tuples:

    string       name
    string       data

The name field identifies the constraint and the data field encodes
constraint-specific information (see below). All constraints are
"critical", if an implementation does not recognise a constraint
then the validating party should refuse to accept the certificate.

The supported constraints and the contents and structure of their
data fields are:

Name                    Format        Description
-----------------------------------------------------------------------------
force-command           string        Specifies a command that is executed
                                      (replacing any the user specified on the
                                      ssh command-line) whenever this key is
                                      used for authentication.

permit-X11-forwarding   empty         Flag indicating that X11 forwarding
                                      should be permitted. X11 forwarding will
                                      be refused if this constraint is absent.

permit-agent-forwarding empty         Flag indicating that agent forwarding
                                      should be allowed. Agent forwarding
                                      must not be permitted unless this
                                      constraint is present.

permit-port-forwarding  empty         Flag indicating that port-forwarding
                                      should be allowed. If this constraint is
                                      not present then no port forwarding will
                                      be allowed.

permit-pty              empty         Flag indicating that PTY allocation
                                      should be permitted. In the absence of
                                      this constraint PTY allocation will be
                                      disabled.

permit-user-rc          empty         Flag indicating that execution of
                                      ~/.ssh/rc should be permitted. Execution
                                      of this script will not be permitted if
                                      this constraint is not present.

source-address          string        Comma-separated list of source addresses
                                      from which this certificate is accepted
                                      for authentication. Addresses are
                                      specified in CIDR format (nn.nn.nn.nn/nn
                                      or hhhh::hhhh/nn).
                                      If this constraint is not present then
                                      certificates may be presented from any
                                      source address.

$OpenBSD: PROTOCOL.certkeys,v 1.3 2010/03/03 22:50:40 djm Exp $

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Mar 2010 13:55:53 -0500

> in interoperating with these certificates then I'm willing to write this

On the one hand I think a simpler PKI than PKIX is always appealing.  On
the other hand I think that any simpler-than-PKIX PKI spec had better
get some things right, foremost, I think, is the OCSP model of
revocation instead of CRLs.

OCSP is often used in this manner: the user agent gets an OCSP Response
for its cert then presents both to relying parties.  I like to think of
OCSP as a ticketing system not too unlike Kerberos.  You start with a
long-term key pair and certificate issued by a long-term CA, present it
to an "online CA" that issues short-term certificates attesting that
long-term ones are still valid, and then you use both certs to
authenticate to relying parties.

It's also useful, I think, to state all trade-offs explicitly.  For
example, a certificate might not bear anything like subject and subject
alternative names or other data useful for authorization, leaving RPs to
handle authorization entirely on their own.  Or a certs might not bear
names or other such data but a directory might be used to lookup such
things using a cert (issuer&serial, whatever) as a lookup key.  In the
latter case there's a requirement for online infrastructure, much as in
the case of OCSP, Kerberos, ...  But even a PKI with CRLs requires
online infrastructure for CRL distribution.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Mar 2010 14:31:39 -0500

> any principal of the specified type. XXX DNS wildcards?

Er, can usernames contain @domain qualifiers?  How should usernames
without an @domain qualifier be handled by servers?

Nico
--

---

From: Damien Miller <[email-masked]>
Date: Wed, 17 Mar 2010 06:54:00 +1100 (EST)

> without an @domain qualifier be handled by servers?

Presently, usernames are interpreted locally. I'd like to support domain-
scoped usernames but deliberate left it out of the initial implementation
until I had a chance to gather and think about the requirements some more.
I had a couple of ideas on how to make it useful:

1) Support another type "SSH_CERT_TYPE_USER_HOST" that includes the
   qualifiers

2) Encode domain qualifiers as a certificate constraint

3) Encourage a mapping between principal names encoded in the cert and
   local usernames to be implemented in the SSH server.

I'm leaning towards #3 - having (in OpenSSH-parlance) an
"authorized_principals" file that specifies which principals are permitted
for an account.

-d

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Tue, 16 Mar 2010 15:29:04 -0400

I second Nicolas's concern. Your spec doesn't even mention revocation. 
How is revocation handled? Are the keys expected to be certified only 
for a very short term?

If certification is expected to be for only a very short term, are you 
putting an infrastructure in place that allows a client to obtain a 
fresh certificate before it connects?

If you are putting such infrastructure in place, do you have a spec for 
how the client obtains the fresh certificate?

Otherwise, if you are planning for these certificates to be long-term, 
what is your solution for revocation?

----- Original Message ----- 
From: "Nicolas Williams" <[email-masked]>
To: "Damien Miller" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 16, 2010 14:55
Subject: Re: OpenSSH certified keys

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 16 Mar 2010 15:34:34 -0400

> inducing collisions in the signature hash infeasible.

Except that you've put it so late in the "certificate" that it's not 
terribly useful for that purpose against current attacks.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 16 Mar 2010 15:42:53 -0400

> (syntactically or sematically) of X.509.

That's unfortunate, because it's what the rest of the world already has as 
its infrastructure.  By not supporting it, you force people to choose 
between supporting your odd, proprietary, unproven certificate format or 
not getting to use certificates at all.  Guess which one anyone with more 
than 5 machines is going to choose?

OpenSSH would be a lot more useful if it supported the same authentication 
mechanisms as the rest of the world.

> be signed by a DSS CA key and vice-versa.

This seems like a serious shortcoming.  Practically no one uses 
single-level certificate heirarchies any more; there's nearly always at 
least one intermediate CA for operational and security reasons.  Taking out 
this feature makes the system less secure.

>  ...
>                                       should be permitted. X11 forwarding
> will                                       be refused if this constraint
> is absent.

This is a poor combination, because it means that the server must 
understand all the things I am allowed to do, even if it doesn't implement 
them.  And really, "permit foo" is not a constraint at all; it's the 
reverse of a constraint.

I recommend _both_ inverting the sense of the "permit-*" items _and_ 
allowing for non-critical extensions, which are often essential for 
extending a protocol in a meaningful way.

-- Jeff

---

From: Damien Miller <[email-masked]>
Date: Wed, 17 Mar 2010 07:45:24 +1100 (EST)

> what is your solution for revocation?

For OpenSSH, revocation is implemented as a simple list of banned keys.
Since keys are the entity that is revoked and not certificates, and 
because there are no wire-side changes require for revocation, I don't
really see it as part of this certificate specification.

-d

---

From: der Mouse <[email-masked]>
Date: Tue, 16 Mar 2010 16:54:53 -0400 (EDT)

>> In particular, we are not comfortable with the complexity
> That's unfortunate, because it's what the rest of the world already
> has as its infrastructure.

This is clearly some unusual definition of "world" I'm not familiar
with.  I'm familiar with three sites' setups.  One of them uses X.509
for nothing at all.  Another does likewise as far as I can tell, but
I'm not quite familiar enough with it to be sure there isn't something
lurking in a corner I haven't seen.  A third uses X.509 certificate
format, but with a private root CA they've set up for their own
purposes; I don't know enough about X.509 to know whether this means
they don't conform to it or not.  (If the software they're using it
with supported something less onerous, they very probably would have
used that instead.)

In none of those three cases is X.509 "what they have as their
infrasturcture".

> By not supporting it, you force people to choose between supporting
> your odd, proprietary, unproven certificate format or not getting to
> use certificates at all.

Or, of course, using some other ssh implementation.

> Guess which one anyone with more than 5 machines is going to choose?

Speaking as someone with more than 5 machines, I have even less
interest in X.509 than I do in this new certificate scheme.  X.509 is
about what you'd expect from design-by-committee: over-complicated,
difficult to use, and blithely oblivious to the ways in which its
underlying assumptions are at odds with day-to-day reality.

> OpenSSH would be a lot more useful if it supported the same
> authentication mechanisms as the rest of the world.

Again this odd value of "rest of the world".

X.509 support might be nice to have (though I'm certainly not going to
bother writing the code).  But I'm glad to see experiments with
alternatives as well; monocultures are bad things.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Mar 2010 16:12:11 -0500

On Tue, Mar 16, 2010 at 03:42:53PM -0400, Jeffrey Hutzelman wrote:
> has as its infrastructure.  By not supporting it, you force people
> to choose between supporting your odd, proprietary, unproven
> certificate format or not getting to use certificates at all.  Guess
> which one anyone with more than 5 machines is going to choose?

If this is billed as a simple PKI for small environments then I think
that's fine.  But if anyone tries to grow a deployment of this PKI much
larger then they'll either need to switch to PKIX, to Kerberos, or
you'll need to grow your PKI protocol to cover their needs.  Growing
this PKI protocol puts it in direct competition with PKIX.  The rest of
us will need some compelling rationales for implementing a competitor to
PKIX, and those are going to be hard to come by because of the very
large deployed base of PKIX.

> authentication mechanisms as the rest of the world.

I agree.  We really should finish the SSHv2-with-x.509 spec, or else
finish PKU2U and deploy that.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Mar 2010 14:45:26 -0500

How will extensions to this PKI cert format be handled?  I see nothing
about criticality...

I understand the aversion to PKIX, which probably derives from an
aversion to x.500-style naming, ASN.1 and BER/DER/CER.  But there are
more lessons to be learned from PKIX than "x.500 sucks" and "BER sucks".

I also understand the intention of having a simple cert format just for
use with SSHv2.  But SSHv2 doesn't exist in isolation.  People use it in
environments where they use Kerberos, so we've added extensions to allow
the use of GSS-API mechanisms and, through that, Kerberos.  Similarly
for PKIX.  If this cert format becomes popular then people will want to
use it elsewhere for the simple reason that having more than one
credentials/authentication infrastructure sucks.

To me this means that we have to ask whether this is desirable right
now.  If it becomes popular then, of course, it sure will be desirable
(and to be sure, I think the OpenSSH team certainly has the ability to
make this protocol popular).  Which means that we'd better get some
aspects of this Right right now; at minimum these issues have to be
handled correctly from day 1:

 - revocation (PKIX lesson: CRLs _suck_)
 - extensibility (how to add critical and non-critical cert elements)
 - principal naming (there's more than just 'hostnames' and 'usernames')
 - federation / CA naming / PKI hierarchies, including mapping to the
   DNS (you might rely entirely on DNSSEC for hierarchy, that'd be a
   fine solution)

Implementation-wise I urge to to make this as much library-like as
possible, so that eventually you can make a trivial GSS-API mechanism
out of it.

Nico
--

---

From: William Ahern <[email-masked]>
Date: Tue, 16 Mar 2010 14:14:45 -0700

> mechanisms as the rest of the world.

IMO the complexity of ASN.1 is overstated. But the fact of the matter is
that there aren't any decent--simple and small--ASN.1 C libraries (or Perl
or any other language for that matter).

There's one very good free compiler, asn1c: http://lionet.info/asn1c/

I've used it extensively for internal cluster messaging. asn1c supports
asynchronous I/O as the parsers it generates are restartable. But it's also
perhaps too heavy weight. A more useful ASN.1 compiler, IMO, would support
member arrays rather than only pointers, and generate much less code for
common types.

That said, OpenSSH already had time-tested building blocks; specifically the
SSH protocol and implemention. "[T]he serialised wire encoding of [the]
certificates is also used for storing them on disk." Of course ASN.1 would
be "too complex" for OpenSSH when minimal code needs to be written when
re-using the existing string parsers and other infrastructure.

ASN.1 will continue to sit on the sidelines in the FOSS world as long as
there's no appealing library and/or compiler to make it the easy choice for
people. Indeed, using ASN.1 in a new proprietary product or protocol is a
very good way to keep FOSS competition at bay.

---

From: Damien Miller <[email-masked]>
Date: Wed, 17 Mar 2010 09:52:04 +1100 (EST)

On Tue, 16 Mar 2010, Jeffrey Hutzelman wrote:

> That's unfortunate, because it's what the rest of the world already has as its
> infrastructure.  By not supporting it, you force people to choose between
> supporting your odd, proprietary, unproven certificate format or not getting
> to use certificates at all.  Guess which one anyone with more than 5 machines
> is going to choose?
> 

Well, unfortunately we consider the additional complexity and attack surface
added by X.509 to be too great. That being said, there are well-maintained
3rd party patches to OpenSSH that support X.509 certificates if users have
a need that isn't supported by this mechanism.

> This seems like a serious shortcoming.  Practically no one uses single-level
> certificate heirarchies any more; there's nearly always at least one
> intermediate CA for operational and security reasons.  Taking out this feature
> makes the system less secure.

I disagree with this too. This certificate format isn't saddled with X.509's
one-PKI-to-bind-them mentality and doesn't have to be singly-rooted. 
OpenSSH supports simultaneous trust of multiple CA keys, so this deals
with CA key revocation and rollover differently.

> This is a poor combination, because it means that the server must understand
> all the things I am allowed to do, even if it doesn't implement them.  And
> really, "permit foo" is not a constraint at all; it's the reverse of a
> constraint.
> 
> I recommend _both_ inverting the sense of the "permit-*" items _and_ allowing
> for non-critical extensions, which are often essential for extending a
> protocol in a meaningful way.

I agree that the term "constraint" may be something of a misnomer, but
disagree that the sense of the extension should be flipped. The intention
here is that new protocol features should not be automatically granted to
old certificates. If the "constraints" _disable_ protocol features then
they will inherit whatever ambient permissions may be added in the future.

wrt non-critical extensions. This is a possibility, via the "reserved"
field in the future if they are really necessary.

-d

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 16 Mar 2010 19:11:07 -0400

--On Wednesday, March 17, 2010 09:52:04 AM +1100 Damien Miller 
<[email-masked]> wrote:

> Well, unfortunately we consider the additional complexity and attack
> surface added by X.509 to be too great. That being said, there are
> well-maintained 3rd party patches to OpenSSH that support X.509
> certificates if users have a need that isn't supported by this mechanism.

As I said, that's unfortunate.

>> least one intermediate CA for operational and security reasons.  Taking
>> out this feature makes the system less secure.
>
> I disagree with this too. This certificate format isn't saddled with
> X.509's one-PKI-to-bind-them mentality and doesn't have to be
> singly-rooted.  OpenSSH supports simultaneous trust of multiple CA keys,
> so this deals with CA key revocation and rollover differently.

I see no such mentality.  The several most widely-deployed X.509 
implementations all support multiple trust anchors, and both X.509 and PKIX 
contemplate the possibility of such.  However, that's not a sufficient 
answer to scalability issues that multi-level PKI's solve.  It also doesn't 
allow for the sorts of cutouts that allow one to sign certificates on a 
regular basis while keeping the secret key for the widely-distributed trust 
anchor offline and under lock and key, which is important given the 
operational impact of having to revoke that key.

BTW, saying you revoke keys rather than certificates doesn't really do 
much.  Who is authorized to revoke a key?  How is that information 
distributed.  A server configuration option that must be manually 
maintained on each SSH server is not really a scalable solution to this 
problem, especially when the majority of servers are not operated by the 
same person as the CA.

> old certificates.

That's fine, but should be up to the CA.  For example, one might have a 
constraint that prohibits use of (some class of) protocol features other 
than ones explicitly listed.  In your model, not only is there no way to 
issue a certificate which can be used with any protocol features including 
new ones, there is also no way to issue a certificate which allows use of a 
new protocol feature but can be also used with servers that do not yet 
support that feature.  That means I need a separate certificate for every 
permutation of features supported by the servers I use, which again is not 
scalable.

If the "constraints" _disable_ protocol features then
> field in the future if they are really necessary.

But you haven't defined how the reserved field will work, or what it MUST 
contain in the current protocol.  So not only is it impossible for anyone 
to define such an extension without "taking over" this field (and you've 
defined no means of coordination for that); you've actually made it 
impossible to use the field at all, because no one can predict what 
existing servers will do with it or what it might contain in existing 
certificates.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 16 Mar 2010 19:16:19 -0400

--On Tuesday, March 16, 2010 02:14:45 PM -0700 William Ahern 
<[email-masked]> wrote:

> there's no appealing library and/or compiler to make it the easy choice
> for people. Indeed, using ASN.1 in a new proprietary product or protocol
> is a very good way to keep FOSS competition at bay.

You mean, except for widely-deployed protocols like PKIX, Kerberos, SNMP, 
and LDAP, all of which have multiple open-source implementations.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA

---

From: Damien Miller <[email-masked]>
Date: Wed, 17 Mar 2010 10:22:42 +1100 (EST)

On Wed, 17 Mar 2010, Roumen Petrov wrote:

> I think that one of issue to previous drafts (O. Saarenmaa and J.
> Galbraith) as Damien point to this list was that ssh server has to
> parse asn.1.

At present, the SSH server doesn't have to parse ASN.1. The ssh-rsa
signature format does *use* ASN.1 encoding, but it is enough of
a canonical representation that a general parser is not needed.
Avoiding the use of ASN.1 here has saved OpenSSH from a few bugs in
OpenSSL's ASN.1 routines over the years. BTW, that several other ASN.1
implementations have suffered from multiple bugs over the years is (to
me at least) a good signal that the format itself is problematic.

See http://anoncvs.mindrot.org/index.cgi/openssh/ssh-rsa.c?revision=HEAD
for more details.

> If I understand Damien most acceptable is solution is if ssh could
> read without to process(parse) certificate(s) data and to pass to
> external system for further processing. Damien ?

I don't think there is much getting away from the fact that there is
a lot of complexity in the pre-auth path when adding X.509. While
delegating verification and authorisation decisions to a sandboxed agent
outside the SSH server is an improvement, the complexity is still in the
critical path.

-d

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Tue, 16 Mar 2010 19:40:08 -0400

Damien,

> For OpenSSH, revocation is implemented as a simple list
> of banned keys. Since keys are the entity that is revoked
> and not certificates, and because there are no wire-side
> changes require for revocation, I don't really see it as
> part of this certificate specification.

does this list of banned keys need to be manually deployed to each 
server, or does OpenSSH support a protocol for retrieving this list 
remotely?

If the list of banned keys must be manually deployed, then this sounds 
worse than CRL. In this case, you're introducing a scheme which allows 
new keys to be added centrally, but requires manually updating the 
configuration of each server when keys are revoked.

On the other hand, if OpenSSH is capable of retrieving the list of 
banned keys periodically, then the protocol for doing so is of interest 
to other implementors as well. If one intends to interoperate with the 
OpenSSH certificate format, then one should certainly support retrieving 
the list of banned keys as well.

denis

----- Original Message ----- 
From: "Damien Miller" <[email-masked]>
To: "denis bider \(Bitvise\)" <[email-masked]>
Cc: "Nicolas Williams" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 16, 2010 16:45
Subject: Re: OpenSSH certified keys

-d

---

From: Damien Miller <[email-masked]>
Date: Wed, 17 Mar 2010 10:54:33 +1100 (EST)

On Tue, 16 Mar 2010, Jeffrey Hutzelman wrote:

> > > single-level certificate heirarchies any more; there's nearly
> > > always at least one intermediate CA for operational and security
> > > reasons. Taking out this feature makes the system less secure.
> >
> > I disagree with this too. This certificate format isn't saddled
> > with X.509's one-PKI-to-bind-them mentality and doesn't have to be
> > singly-rooted. OpenSSH supports simultaneous trust of multiple CA
> > keys, so this deals with CA key revocation and rollover differently.
>
> implementations all support multiple trust anchors, and both X.509
> and PKIX contemplate the possibility of such. However, that's not a
> sufficient answer to scalability issues that multi-level PKI's solve.
> It also doesn't allow for the sorts of cutouts that allow one to sign
> certificates on a regular basis while keeping the secret key for the
> widely-distributed trust anchor offline and under lock and key, which
> is important given the operational impact of having to revoke that
> key.

A similar operational effect could be achieved by having additional
trusted CA keys established ahead of time and securely placed in reserve
for the case where a primary CA key is compromised. Next?

In case you are wondering, recursive verification is not included for
reasons of conceptual and implementation simplicity. 

> BTW, saying you revoke keys rather than certificates doesn't really
> do much. Who is authorized to revoke a key? How is that information
> maintained on each SSH server is not really a scalable solution to
> this problem, especially when the majority of servers are not operated
> by the same person as the CA.

I don't really see the mechanism of key revocation as part of the
certificate _format_. Just because X.509 includes it there isn't a
strong reason that others need to do so.

In answer to your question, the current OpenSSH implementation supports
a text file of revoked keys distributed out of band. This isn't
scalable, but it isn't the only possibility; it wouldn't be hard to
define an online method of testing key revocation (a la OCSP), perhaps
via a new SSH subsystem. A defined subsystem for enrolling keys would
be nice, but that is outside the scope of the certificate format
description too.

> > I agree that the term "constraint" may be something of a misnomer,
> > but disagree that the sense of the extension should be flipped.
> > The intention here is that new protocol features should not be
> > automatically granted to old certificates.
>
> That's fine, but should be up to the CA. For example, one might
> have a constraint that prohibits use of (some class of) protocol
> features other than ones explicitly listed. In your model, not only
> is there no way to issue a certificate which can be used with any
> protocol features including new ones, there is also no way to issue
> a certificate which allows use of a new protocol feature but can be
> also used with servers that do not yet support that feature. That
> means I need a separate certificate for every permutation of features
> supported by the servers I use, which again is not scalable.

That is a fair point and it is potentially worth reconsidering the
criticality of certificate extensions because of it. I think that
in the presence of non-critical extensions though, the sense of the
extensions is more important; if a non-critical extension that disables
some protocol feature is skipped by an implementation that does not
understand it (but does implement the protocol feature), then there are
more security consequences than the converse.

> If the "constraints" _disable_ protocol features then > they will
> inherit whatever ambient permissions may be added in the future. > >
> But you haven't defined how the reserved field will work, or what it
> MUST contain in the current protocol. So not only is it impossible
> for anyone to define such an extension without "taking over" this
> field (and you've defined no means of coordination for that); you've
> actually made it impossible to use the field at all, because no one
> can predict what existing servers will do with it or what it might
> contain in existing certificates.

The document I sent is not set in stone (clearly; it was sent
for feedback) and there is only one server that implements it,
which happens to ignore this field's contents. So using it as an
extensibility mechanism is a simple matter of clarifying its intent in
the specification.

-d

---

From: Damien Miller <[email-masked]>
Date: Wed, 17 Mar 2010 10:58:13 +1100 (EST)

> the list of banned keys as well.

The list of revoked keys is just a file on disk and OpenSSH implements
no special means to update it (so far). We could define some distribution
service or an online protocol to lookup key revocation status, possibly
as a SSH subsystem.

-d

---

From: Roumen Petrov <[email-masked]>
Date: Wed, 17 Mar 2010 01:08:48 +0200

Hi Jeffrey,

Damien Miller wrote:
>>> user and host keys. [SNIP]
>>

I think that one of issue to previous drafts (O. Saarenmaa and J. 
Galbraith) as Damien point to this list was that ssh server has to parse 
asn.1.
If I understand Damien most acceptable is solution is if ssh could read 
without to process(parse) certificate(s) data and to pass to external 
system for further processing.
Damien ?

The recent draft (K. Igoe and D. Stebile 
http://tools.ietf.org/html/draft-igoe-secsh-x509v3-01 ) didn't resolve 
this issue.

[SNIP]

Roumen

---

From: William Ahern <[email-masked]>
Date: Tue, 16 Mar 2010 17:29:47 -0700

> and LDAP, all of which have multiple open-source implementations.

All of those protocols were created in the 1990's. Each open source
implementation wrote their own implementation of the relevant ASN.1 codecs,
largely only suited to their particular task. And they did so because the
particular protocol was already ubiquitous. Only SNMP has a significant
number of open source implementations, and SNMP is simplified.

AFAIK, there are no recent protocols that have used ASN.1. In fact, most use
XML largely because of the ubiquity of Clark's expat and, subsequently,
GNOME's libxml. (Hype obviously played a part, but those susceptible to hype
aren't as well represented in the class of those able to write decent
infrastructure software.)

The only library that OpenSSH currently depends on is OpenSSL, and their
implemention is horrible by their own admission (and manifestly
untrustworthy). OpenSSH is a conservative project, existing implementations
aren't suitable (and they'd have to be exceptional, I think, for OpenSSH to
accept a new dependency), and the project is understandably reticent to
write a huge new chunk of code.

If ASN.1 is to garner mindshare (and respect), it minimally needs something
like expat to reduce costs. As things stand, unless you work in telecom
there's no future for ASN.1. ASN.1 isn't on anyone's radar. Look at
phenomena like Google's Protocol Buffers. That and similar projects provide
nothing more (and usually not much less, either) than ASN.1. Why go thru the
bother of writing a new specification _and_ new code? It's not logical to my
mind, but that's the way things are. ASN.1 isn't as simple as line-oriented
protocols (which are in abundance), nor are there any best-of-breed
implementations. Therefore you see a flourishing of ad hoc designs.

---

From: Douglas Stebila <[email-masked]>
Date: Wed, 17 Mar 2010 10:04:50 +1000

The OpenSSL certkeys protocol has some similarities to our present X.509-in-SSH proposal, but also differs in at least three major ways; there are some lessons for each to learn from the other, but there are also some fundamental incompatibilities.

User/host identifiers: Our draft leaves the mapping between certificates and usernames / hostnames up to the implementation and system administrators.  Perhaps we should revisit the issue of mapping hostnames, but I believe that having the CA map certificates to usernames is inappropriate.  The same user (with the same certificate) may intend to use that certificate with multiple servers, and have different usernames on each server.  For example, on their primary work computer the user may have the username "admin", and on their departmental web server have the username "bsmith"; but the administrator of the departmental web server may not wish to allow that user to access the web server as "admin".

Revocation: At the request of members of this list, our draft -01 incorporated a mechanism for a party to relay certificate status / revocation information (specifically, OCSP responses) along with any certificates delivered during the exchange.  I was convinced by arguments made by members of this list that checking revocation is an important feature, and moreover that clients in particular may not have online access to a certificate status server.  For example, if a client is logging into a corporate network and the certificate status server is inside the corporate network, then the client cannot access the network to verify the status of the certificate.

Constraints: We did not include any SSH-specific constraints in our draft.  I have no opinion whether including such constraints is appropriate or not, and there seems to be some discussion going on right now about this.

X.509 versus not X.509: Obviously the main difference is the certificate format.  We started from the premise that "people want to use their PKIX infrastructure in SSH", and it appears, Damien, that you and your colleagues started from the premise that "people want to use some kind of certificates in SSH".  But you've also later written in this thread:
> Well, unfortunately we consider the additional complexity and attack surface added by X.509 to be too great.
Is it that you (a) consider all existing implementations of X.509 to be too untested and thus have an unacceptable attack surface or (b) consider the X.509 specification itself to be too complex to ever have an acceptable implementation?  If it's (a), then there's at least a hope for reconciliation between our approach and yours.  If it's (b), then to me that says the maintainers of the most popular SSH implementation will not ever accept the use of X.509 certificates in SSH.

Douglas

---

From: Konstantin Andreev <[email-masked]>
Date: Wed, 17 Mar 2010 14:44:28 +0300

> (syntactically or sematically) of X.509.

I am not a security expert.

I can only rely on protocols/solutions, that trustworthy experts assert to be secure, or authoritative government institution certifies as secure.

What have I from this point of view ?

I can be sure that X.509 PKIX was designed and reviewed by the best experts in the industry. I can be sure, that all details I have never heard about were taken into account. There are approved guides which help me reach the highest level of the X.509 security.

Can I be sure that security protocol, designed by self-taught security experts, reaches that level of security or has not hidden defects? Nope.

IMO, being "not comfortable" with X.509 features is not enough to reimplement the wheel...

Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 17 Mar 2010 11:17:19 -0500

On Wed, Mar 17, 2010 at 10:58:13AM +1100, Damien Miller wrote:
> > > of banned keys. [...]
> > [...]

Why repeat mistakes of the past?  What is the point of this PKI scheme
other than "ASN.1/BER/x.500/... is too complex"?  Why should anyone do
any work to help standardize a protocol that improves on predecessors in
only one [debatable] manner while taking steps backwards relative to
predecessors in several important aspects?

Areas of this protocol's design that repeat mistakes of the past or
where new mistakes are made:

 - extensibility and criticality
 - hash collision attacks
 - revocation
 - hierarchy/bridging
 - separation of online vs. off-line keys

And there's a bevvy of sub-protocols missing, such as certificate
singing requests.  As for your protocol's simplicity, that's ephemeral
-- or do you believe that your protocol can remain simple enough for
your tastes should it become popular?

The arguments over ASN.1's and BER/DER/CER's complexity are specious.
ASN.1's syntax is hard to parse, but it's also easy to come up with
alternatives that parse well.  XER proves that by and large ASN.1 and
XML schemas have equivalent expressive power.  PER can be seen as a
byte-aligned variant of XDR, with slight differences in the handling of
optional sequence elements and choice selection.  I'd argue that
redundancy of encoding is the main source of vulnerabilities in
encoding/decoding code, and that redundancy/verbosity is a problem for
XML as well as BER, yet XML is all the rage.  Perceived simplicity
clearly matters for a lot of implementors, but that should not excuse
the repetition of mistakes outside the choice of syntax and encoding.

Nico
--

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Fri, 19 Mar 2010 20:31:23 -0400

Good points, Nicolas.

More often than not, however, the quick and dirty implementation will 
succeed in the market simply because it's there and gets the job 
approximately done when the rigorous solution is still in its design 
phases.

The ubiquity of Unix-like computer architecture is testament to this. 
Something like Smalltalk would have been rigorous and better, but the 
quick and dirty Unix was there and did the job approximately done 
faster. The market share of Windows is another bit of evidence.

The question is, will users be satisfied enough with the OpenSSH 
certified keys format that we'll all have to implement it. If that 
happens, it is in our interest to help the OpenSSH team fix any spec 
problems before we have to implement something even less optimal than it 
otherwise could be.

I would hope that users will not be satisfied with this solution and 
will demand a more rigorous implementation, but that remains to be seen.

denis

----- Original Message ----- 
From: "Nicolas Williams" <[email-masked]>
To: "Damien Miller" <[email-masked]>
Cc: "denis bider \(Bitvise\)" <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, March 17, 2010 12:17
Subject: Re: OpenSSH certified keys

Nico
--

---

From: [email-masked] (Niels Möller)
Date: Sun, 21 Mar 2010 21:39:49 +0100

> (syntactically or sematically) of X.509.

I don't have time to look into the details at the moment, but it makes a
lot of sense to me to

(1) use certificates, e.g., to use a single key to certify hostkeys for
    a set of machines in the same administrative domain, and to enable
    users to delegate limited access to other keys, and

(2) avoid the x.509 mess.

Since my plan (which I haven't got around to implementing in a long
time) have been to support spki certificates, my first question is how
this certificate structure relates to spki?

In spki, one has a fairly simple machine that processes lists of
certificates, and then one have to choose a representation for the
application specific stuff as "tags" in the acl:s and certificates in
such a way that the machine gives the desired semantics when processing
them. E.g, I use hostkey acl:s of the form

(acl (entry (subject (public-key (rsa-pkcs1-sha1 (n |AM2/AtKFQ83sG1QMOG2
                                                     TnKegZz8GSd7ZrO5yS3
                                                     2DBriPYSLPPoleXTC9U
                                                     JIdA2YhN0vkXq3jWOkR
                                                     enqVNapK4Iiaj354M68
                                                     RGYcE38QhBLo7Sz1+U/
                                                     MDHcD//Dwehn8NFBK02
                                                     h8LMuuw5D2+RAZDm7fy
                                                     +oKSIPjL/D0hX+tGnZ7
                                                     1|)
                                                 (e "#"))))
            (tag (ssh-hostkey se.liu.lysator.stalhein))))

Note the reversed dns name. This choice of representation in the tag
makes it possible to use the prefix-feature in the spki machinery to use
a certificate that allows a key to sign hostkeys for any machine in a
given domain. I expect that the constraints you list can also be
represented, with some trickery like above needed only for the
source-address constraint.

> The supported constraints and the contents and structure of their

This constraint removes a capability (that of executing arbitrary
commands).

>                                       be refused if this constraint is absent.

While this and most of the other "constraints" *adds* a capability.

Having both positive and negative constrints seems like it makes it less
straightforward when combining all constraints in a certificate chain
(which represents delegation of authority). In spki, all constraints
sets limits on authority, and then when combining a chain of
certificates the constraints applied to the key is simply the union of
the constraints present in some certificate or in the top-level acl
entry. The opposite model where all constraints adds capabilitis is
equally simple, then one takes the intersection instead of union.

But when you have both positive and negative constraints, then the
certificate chain machinery has to be aware of the semantics of each
constraint, which I think is one reason why x.509 is hairy.

An alternative design would be either have allow-command (with some
meachnism to specify "any", or more generally, somehow specify a set of
allowed commands, e.g., specifying a command prefix or a regexp), or
no-X11-forwarding.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.