Certificate spec anomaly?

[Damien Miller]

On Mon, 19 Sep 2022, Brian Candler wrote:

> I have had the following potential inconsistency pointed out to me, and 
> I thought I'd raise it here.
> 
> On the one hand, OpenSSH by default doesn't allow authentication using a 
> certificate with no principals[^1]. From sshd_config(5):
> 
>  > Note that certificates that lack a list of principals will not be 
> permitted for authentication using TrustedUserCAKeys.
> 
> On the other hand, the spec at 
> https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.certkeys?rev=1.19&content-type=text/x-cvsweb-markup 
> says:
> 
>  > As a special case, a zero-length "valid principals" field means the 
> certificate is valid for any principal of the specified type.
> 
> I think the behaviour of sshd is sane and sensible. A 
> "super-certificate" which can impersonate any user (or any host[^2]) 
> seems like a dangerous thing to me; especially since it's what you get 
> by default if you omit the -n option to ssh-keygen -I.  There are other 
> SSH CAs which may generate this sort of certificate if you don't request 
> any principal (e.g. Hashicorp Vault).  Rejecting it seems the safer option.
> 
> I wonder if the protocol documentation is out of step, or if I've missed 
> a subtlety?

The no-principals case was intended to support user-specified (as
opposed to admin-specified) trust anchors. E.g. in ~/.ssh/authorized_keys
Certificates accepted by the system-wide TrustedCAKeys are required to
have a principal present.

> AFAICT, this allows anyone with *any* user certificate signed by the CA 
> to authenticate, with or without principals. That's clearly less than 
> ideal, but at least it was configured explicitly on this account, and 
> the attack surface is limited to that one particular account.

Right, that's the use-case.

-d