Chris Lonvick | 11 Mar 16:15 2010
Picon

Progress on draft-igoe-secsh-x509v3?

Hi,

I havn't seen too much discussion on the list about the ID lately.  Is it 
ready to go to the IESG?

If there is still some grey areas that need to be addressed, what do 
people think of getting together in Anaheim to go over them?

Regards,
Chris

Damien Miller | 16 Mar 18:19 2010

OpenSSH certified keys

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.
(Continue reading)

Nicolas Williams | 16 Mar 19:55 2010
Picon

Re: OpenSSH certified keys

On Wed, Mar 17, 2010 at 04:19:28AM +1100, Damien Miller wrote:
> 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.

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
(Continue reading)

Nicolas Williams | 16 Mar 20:31 2010
Picon

Re: OpenSSH certified keys

On Wed, Mar 17, 2010 at 04:19:28AM +1100, Damien Miller wrote:
> "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?

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

Nico
--

-- 

Damien Miller | 16 Mar 20:54 2010

Re: OpenSSH certified keys

On Tue, 16 Mar 2010, Nicolas Williams wrote:

> On Wed, Mar 17, 2010 at 04:19:28AM +1100, Damien Miller wrote:
> > "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?
> 
> Er, can usernames contain  <at> domain qualifiers?  How should usernames
> without an  <at> 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.

(Continue reading)

denis bider (Bitvise | 16 Mar 20:29 2010

Re: OpenSSH certified keys

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" <Nicolas.Williams <at> sun.com>
To: "Damien Miller" <djm <at> mindrot.org>
Cc: <ietf-ssh <at> NetBSD.org>
Sent: Tuesday, March 16, 2010 14:55
Subject: Re: OpenSSH certified keys

On Wed, Mar 17, 2010 at 04:19:28AM +1100, Damien Miller wrote:
> 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
(Continue reading)

Jeffrey Hutzelman | 16 Mar 20:34 2010
Picon

Re: OpenSSH certified keys

--On Wednesday, March 17, 2010 04:19:28 AM +1100 Damien Miller 
<djm <at> mindrot.org> wrote:

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

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

Jeffrey Hutzelman | 16 Mar 20:42 2010
Picon

Re: OpenSSH certified keys

--On Wednesday, March 17, 2010 04:19:28 AM +1100 Damien Miller 
<djm <at> mindrot.org> wrote:

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

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.

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

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.

> The name field identifies the constraint and the data field encodes
(Continue reading)

Damien Miller | 16 Mar 21:45 2010

Re: OpenSSH certified keys

On Tue, 16 Mar 2010, denis bider \(Bitvise\) wrote:

> 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?

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

der Mouse | 16 Mar 21:54 2010

Re: OpenSSH certified keys

>> In particular, we are not comfortable with the complexity
>> (syntactically or sematically) of X.509.
> 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,
(Continue reading)


Gmane