nats-io
ADR-0005 JWT Authentication Extensibility
Constrain our server auth nonce selection with a no-op change for the current server code-base, in a way which we guarantee and expect clients to check for, to buy us future proofing.
Noop code-change for the server codebase in this repo.
Changes proposed in this pull request:
- A protocol constraint which other code can enforce
- No changes in behavior for the current nats-server code
/cc @nats-io/core
Hrm, might need text to explain why using a different field in the CONNECT message is not sufficient? The MitM can construct the nonce, get the client to do current-gen nonce signing, then move the response to a different field in talking to the server. Is it worth adding this?
The current JWT authentication method means that the private key inside a JWT will sign anything at all. This is the source of a whole class of security attacks, basically making the key absolutely unusable for anything else. At present, we're not using it to sign anything else so we're squeaking by. With any desire to do anything else with JWTs, the current signing method will become a CVE-worthy vulnerability to be addressed.
Either we dead-end JWTs to only ever be used exactly as they are now, or we allow for some kind of structured scope which special-cases the current usage. I think that two CPU instructions on connection to not dead-end a technology which we're justly quite proud of is a small price to pay.
First the private key is never part of the JWT in NATS, they are always public claims. And I agree with signing, but we already have a pattern that utilizes ephemeral signing keys for things beyond basic authentication by signing the nonce.
