nquic_new_token (nquic v1.0.0)
View SourceServer-side NEW_TOKEN issuance and validation per RFC 9000 §8.1.3.
The server hands out an opaque token via the NEW_TOKEN frame after the handshake completes. A returning client echoes the token on its next Initial; if the token validates, the server skips the Retry round-trip and proceeds with handshake immediately.
The token binds the client's IP+port to a freshness timestamp,
authenticated by HMAC-SHA256 with the same static key Retry uses,
domain-separated by the leading "new_token" tag in the HMAC
input so a Retry token cannot be replayed as a NEW_TOKEN token (and
vice versa).
Token format: <<HMAC:32/binary, IssuedAt:64, AddrBin/binary>>
HMAC input: <<"new_token", Lifetime:32, IssuedAt:64, AddrBin/binary>>
Summary
Functions
Generate a NEW_TOKEN token bound to PeerAddr, valid for 24 hours.
Like generate/3 but with an explicit issue time (for testing).
Validate a NEW_TOKEN token against the current peer address.
Functions
-spec generate(binary(), nquic_socket:sockaddr(), pos_integer()) -> binary().
Generate a NEW_TOKEN token bound to PeerAddr, valid for 24 hours.
-spec generate(binary(), nquic_socket:sockaddr(), pos_integer(), non_neg_integer()) -> binary().
Like generate/3 but with an explicit issue time (for testing).
-spec validate(binary(), binary(), nquic_socket:sockaddr()) -> ok | {error, invalid_new_token}.
Validate a NEW_TOKEN token against the current peer address.
-spec validate(binary(), binary(), nquic_socket:sockaddr(), pos_integer()) -> ok | {error, invalid_new_token}.