Re: OpenSSH certified keys

[nisse%lysator.liu.se@localhost (Niels Möller)]

Damien Miller <djm%mindrot.org@localhost> writes:

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

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

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

> permit-X11-forwarding   empty         Flag indicating that X11 forwarding
>                                       should be permitted. X11 forwarding will
>                                       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.