Re: Certificate spec anomaly?

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]


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

openssh-unix-dev mailing list

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux