Revoking a yubikey within a cluster about yubikey-val

[michael-lazar]

Here's what I ended up doing in case anybody stumbles across this issue:

I couldn't come up with a robust + secure way to use /revoke. I didn't like that I had to rely on an IP whitelist for access instead of an API key with more fine-grained permission controls. I also ran into some edge-cases trying to implement synchronization due to the simplistic error handling in the /revoke endpoint.

I decided to go in another direction and approached this from the KSM level. I'm already storing my AEAD keys in a MySQL database, which is being replicated across my cluster. So I added an active flag to the AEAD table:

CREATE TABLE ykksm.aead_table (
  public_id varchar(16) NOT NULL,
  keyhandle INT NOT NULL,
  nonce BLOB(6) NOT NULL,
  aead BLOB(32) NOT NULL,
  active BOOL NOT NULL,
  PRIMARY KEY (public_id, keyhandle)
);

I added some logic to my KSM servers to check the active flag when they try to load a key handle. If it's false, the KSM will return an ERR Disabled public_id failure. This gets bubbled up in the yubikey-val server as a generic BAD_OTP response.

This allows me to sidestep both of the issues that I outlined in my previous post. I've disable the /revoke endpoint and from the validation server's perspective, every yubikey is active now. Our administrators can use the same internal tool to provision new yubikeys into our AEAD database, as well as enable/disable yubikeys if they need to be revoked.

[klali]

I'd say that your last statement is quite true, active isn't implemented enough to be usable with only this project. Yubico used to run a service for revoking keys in YubiCloud, that had it's own queue of revocations in case a server was down.

As the sync protocol looks right now the active flag isn't transmittable over it at all. I guess the easiest way to give something to handle new servers would be to let resync hit the revoke endpoint for inactive identities.