Some wishes regarding revoked keys

[Alexander E. Patrakov]

пт, 7 сент. 2018 г. в 11:57, Damien Miller <djm at mindrot.org>:

>
>
> On Fri, 7 Sep 2018, Alexander E. Patrakov wrote:
>
> > Hello.
> >
> > I am trying to play through the following test scenario about
> > certificate revocation on Ubuntu 18.04, which has OpenSSH of this
> version:
> > OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
> >
> > 1. A CA key is created
> > ssh-keygen -t ed25519 -f ca
> >
> > 2. The CA public key is added to ~/.ssh/authorized_keys on some server:
> > cert-authority ssh-ed25519 AAAA...e ca at yoga
> >
> > 3. A user key is created on a different laptop:
> > ssh-keygen -t ed25519 -f user
> >
> > 4. The CA gets user.pub, signs the user key and applies restrictions,
> > then transfers user-cert.pub back to the user's laptop
> > ssh-keygen -s ca -I user -V 20180906:20180908 -O clear -O permit-pty user
> > (yes I know, at this point the CA has made a mistake of not specifying
> > the unique serial, but still there is a unique ID supplied with "-I
> > user", so nothing fatal)
> >
> > 5. The CA destroys its copy of the user.pub and user-cert.pub files,
> > because a guide (e.g. https://ef.gy/hardening-ssh) says it is a good
> idea.
>
> IMO #4 and #5 are bad CA practices and are the root of your problems.
>
> That being said, I think it's a great idea for the sshd authentication
> log messages to contain enough information to be able to revoke keys
> under all circumstances.
>
> The following patches implement this. They include the cert fingerprint
> in the sshd "Accepted publickey ..." message and allow revocation by
> the fingerprint hash. E.g.
>
> Given the log message of:
>
> Accepted publickey for djm from 127.0.0.1 port 54091 ssh2: RSA-CERT
> SHA256:hNggUg6sCnYZFlaauRzwfqVSRsep3OpSngU7xQEj0ac ID regress user key for
> djm (serial 19564) CA RSA SHA256:b6AasnX04A2zkjc6oWYEPhI01QsjK0h2YmjWdxCMe2U
>
> You'll be able to prepare a KRL spec:
>
> echo "SHA256:hNggUg6sCnYZFlaauRzwfqVSRsep3OpSngU7xQEj0ac" > /tmp/krlspec
> ssh-keygen -kf /tmp/krl /tmp/krlspec
>
> Unfortunately, since I had to add a new KRL section to list keys by
> SHA256 hash, these KRLs will only be readable by OpenSSH with the patch
> (hopefully it will ship in OpenSSH 7.9). A sshd that gets a KRL with
> unknown entries will refuse *all* keys.
>

Thanks for the patch, I will test it later.

However, I don't quite understand why you need a new KRL section (thus,
IMHO unnecessarily, introducing incompatibility). A compatible solution
would be to put a truncated SHA256 hash in the existing section, and search
for it there. The downside would be that old sshds will not refuse that
key, though, and I don't know whether it is acceptable. Anyway, this can
only happen if the admin uses new ssh-keygen and copies the result to a
server with old sshd.

-- 
Alexander E. Patrakov