Does NATS support RFC 9266?

[Brent Kimberley]

Heading says it all: Does NATS support RFC 9266? 

[derek]

We need more context to be honest.

NATS payloads are opaque, so you can encode payloads with Base45 and be fine, but I am not convinced that is why you were asking.

[Phil Pennock]

On 2025-06-22 at 12:00 -0700, Brent Kimberley wrote:
> Heading says it all: Does NATS support RFC 9266?

No.

At this time, no authentication mechanism supported by the NATS server
supports using Channel Binding data at all, let alone the specifics of
TLS 1.3 Channel Binding per RFC 9266.

The closest you're going to get is using mTLS authentication, such that
your client key/cert are verifiable by the server. That would get you
man-in-the-middle detection.

But re Channel Binding: I don't think it's on the roadmaps at all.
This is open source so a well-considered contribution stands a fair
chance of being merged. But "well-considered" is doing a lot of
heavy lifting in that sentence.

Adding a new auth mechanism is non-trivial though, since it would need
to be implemented in the server and in all of the officially supported
client libraries. But you could probably prove it out in the Go
implementation, to get enough interest.

Note that the NATS protocol does not use SASL and I don't think there's
any desire to open up to arbitrary extensibility and plugins here.
We're also generally opposed to raw auth data being exposed to the NATS
server side: enabling password auth triggers logged warnings in the
server.

So the strongest chance of success involves a new nkey signing scheme
which fixes issues in the current scheme and brings along
channel-binding support as part of the story. This would inherently
carry over into the Operator mode authentication too.

If you want to introduce SCRAM auth or the like, then there would be a
lot of pushback and we'd need a strong story on how the NATS server side
communicates with components providing either the raw passwords or the
salted data.

-Phil