Nonce is meant for freshness, not to guarantee one-time use

[c2bo]

Feedback from IETF 122: We should be more clear in the draft that the intention of the nonce is to guarantee freshness, not one-time use (which can be really hard to guarantee depending on deployment etc).

[Denisthemalice]

Step (5) is described as:

(5) The Client Instance generates a Proof of Possession (PoP) with the Client Instance Key.

Before generating a Proof of Possession (PoP) with the Client Instance Key, the client needs to select a mechanism
that can allow the authorization server to detect replays.

In a client - server paradigm, there exit two mechanisms that are able to detect replay attacks that were orinally defined
in ISO/IEC 10181-2:1996. 3.18 (Security frameworks for open systems: Authentication framework — Part 2):

• using a challenge generated and sent by the server to the client, or
• using a unique number generated and sent by the client to the server.

The ISO definitions are as follows:

challenge
A time variant parameter generated by a verifier.
ISO/IEC 10181-2:1996. 3.8 (Security frameworks for open systems: Authentication framework — Part 2)

challenge
data item chosen at random and sent BY THE VERIFIER to the claimant, which is used by the claimant,
in conjunction with secret information held by the claimant, to generate a RESPONSE WHICH IS SENT TO THE VERIFIER
ISO/IEC 9798-1:2010, 3.5 (Security techniques — Entity authentication — Part 1: General)

unique number
A time variant parameter generated by a claimant
ISO/IEC 10181-2:1996. 3.18 (Security frameworks for open systems: Authentication framework — Part 2)

RFC 9449 defines the nonce claim in 12.7.1. "nonce" Registration Update

The Internet Security Glossary [RFC4949]
provides a useful definition of nonce as a random or non-repeating value that is included in data exchanged
by a protocol, usually for the purpose of guaranteeing liveness and thus detecting and protecting against replay attacks.

Claim Name:
nonce
Claim Description:
Value used to associate a Client session with an ID Token (MAY also be used for nonce values in other applications of JWTs)

This is rather general and this does not allow to distinguish between a value generated by a client or by a server.

The current draft is using the word "nonce" in a way that is different from the way it has been used for years
within the ISO community.

The definition of a nonce in the current draft is:

• nonce: OPTIONAL. The nonce (nonce) claim MUST specify a String
  value that is provided BY THE AUTHORIZATION SERVER to associate
  the Client Attestation PoP JWT with a particular transaction and
  PREVENT replay attacks.

Note that this claim cannot PREVENT replay attacks but can be used to DETECT replay attacks.

For this concept, where the String value is provided BY THE SERVER, the term "challenge" is being used within the ISO community.

For the term "nonce", the ISO community is using the following definitions:

nonce
number used once
ISO/IEC 9797-3:2011, 3.3

nonce
value that is used one and only one time to provide uniqueness to a value (e.g., a secure cryptographic key)
in whose derivation it participates or to uniquely identify a single instance of something (e.g., a timestamp)
exchanged between an application client and a device server
ISO/IEC 14776-454:2018, 3.1.95

It is confusing to use the term "nonce" when the term "challenge" is used by the ISO community.

At this time, let us focus on section 11.1 (Replay Attack Detection).

The following mechanisms exist within this client authentication
method in order to allow an authorization server to detect replay
attacks for presented client attestation PoPs:

• The client uses "jti" (JWT ID) claims for the Client Attestation
  PoP JWT and the authorization server maintains a list of used
  (seen) "jti" values for the time of which the JWT would be
  considered valid based on the applicable "exp" claim. If any
  Client Attestation PoP JWT would be replayed, the authorization
  server would recognize the "jti" and respond with an
  authentication error.

• The authorization server provides a nonce for the particular
  transaction and the client uses it for the "nonce" claim in the
  Client Attestation PoP JWT. The authorization server validates
  that the nonce matches for the transaction. This approach may
  require an additional roundtrip in the protocol. The
  authorization server MUST ensure that the nonce provides
  sufficient entropy.

• The authorization server may expect the usage of a nonce in the
  Client Attestation PoP JWT, but instead of providing the nonce
  explicitly, the client may implicitly reuse an existing artefact,
  e.g. the authorization code. The authorization server MUST ensure
  that the nonce provides sufficient entropy.

The approach using a nonce explicitly provided by the authorization
server gives stronger replay attack detection guarantees, however
support by the authorization server is OPTIONAL to simplify mandatory
implementation requirements. The "jti" method is mandatory and hence
acts as a default fallback.

The "jti" claim is defined as in [RFC7519, Section 4.1.7] (see https://www.iana.org/assignments/jwt/jwt.xhtml#claims)

4.1.7. "jti" (JWT ID) Claim
The "jti" (JWT ID) claim provides a unique identifier for the JWT.
The identifier value MUST be assigned in a manner that ensures that
there is a negligible probability that the same value will be
accidentally assigned to a different data object; if the application
uses multiple issuers, collisions MUST be prevented among values
produced by different issuers as well. The "jti" claim can be used
to prevent the JWT from being replayed. The "jti" value is a case-
sensitive string. Use of this claim is OPTIONAL.

This "jti" claim, while it would be capable to support the nonce approach (in the ISO sense), would place a hard burden on the client. It would need to be truly unique during the life time of the client so that it cannot be non-repeating.

Unique numbers can be repeating numbers if the probability of repetition is kept very low. If the same unique number is chosen by two clients and presented to the same server, the one which sucessfully presents it first will succeed while the other one will fail, but it can make another attempt using another unique number. This particular case creates a denial of service, but not in a security breach.

In practice, unique numbers can be supported using two parameters:

• the time at which the Client Attestation PoP ("iat" claim) has been generated, and
• a random number ("rnd" claim) that needs to be unique which a high level of probability
  when associated with the previous value of the time .

The text from section 11.1 (Replay Attack Detection) should be modified to support :

• EITHER a unique number generated by the client
• OR a challenge generated by the authorization server.

In order to avoid confusion, a different name should be used for :

(1) the "value" generated and sent by a client and
(2) the "value" generated and sent by the server

that can be used to detect replays. As an example, they can't both be called a nonce.

This leads to consider the following three claims: "iat", "rdn" (for random number") and "chal" (for challenge).

EITHER, both the "iat" and the "rdn" claims MUST be present OR the "chal" claim MUST be present.

Both mechanisms provide the same replay attack detection guarantees.

The text below is a proposal for revising the text from 11.1 (Replay Attack Detection).

In order to allow an authorization server to detect replay attacks for presented client attestation PoPs,
one out of the two following mechanisms MUST be used:

1. For every Client Attestation PoP JWT, the client generates a unique number (i.e., a number that will unique with a high level
   of probability) that is composed of two claims : a "iat" claim and a "rdn" claim.

For every value of the "iat" claim, the value of the "rdn" claim generated by the client MUST be different. The "rdn" claim
MUST be a pseudo random number that SHOULD be sufficiently large to allow a large number of clients to sucessfully use
the mechanism when they select the same value for the "iat" claim. The "rdn" claim contains a String which SHOULD contain
at least 32 characters.

The authorization server chooses a time window around its current time.

When the authorization server receives a Client Attestation PoP JWT:

a) If a received "iat" claim is outside of this time window, the authorization server would respond with an authentication error.

b) If a received "iat" claim is inside this time window and the associated "rdn" claim can be successfully used to validate
a Client Attestation PoP JWT, then the authorization server adds the values both of the "iat" claim and the associated "rdn" claim
into a list of validated pairs of "iat" and "rdn" claims.

c) If a received "iat" claim is inside this time window and the values both of "iat" claim and of the associated "rdn" claim
are present in the list of validated pairs of "iat" and a "rdn" claims, the authorization server would respond
with an authentication error.

When the value of a "iat" claim from an entry falls outside of the time window, the authorization server SHOULD remove
the entry from the list.

2. Before generating a Client Attestation PoP JWT, the client requests a challenge to the authorization server.
   The authorization server generates a challenge that MUST be unique during a chosen time window.
   The "chal" claim contains a String which SHOULD contain at least 32 characters.

During that time window, the authorization server maintains a list of the challenges which are sent associated
with the time when they are sent.

The client places the received challenge into the "chal" claim in the Client Attestation PoP JWT.

When the authorization server receives a Client Attestation PoP JWT:

a) If this value of the "chal" claim is not present in the list, the authorization server would respond with an authentication error.

b) If this value of the "chal" claim is present in the list and can be successfully used to validate a Client Attestation PoP JWT,
the authorization server removes this value from the list of challenges.

When the value of a current time from an entry falls outside of the time window, the authorization server SHOULD remove
the entry from the list.

The authorization server can recognize which mechanism has been chosen by the client:
If both the "rdn" claim and the "chal" claim are present or if either only the "iat" claim or the "rdn" claim is present,
then the authorization server would respond with an authentication error.
If both the "iat" claim and a "rdn" claim are present, then the first mechanism has been selected by the client.
If the "chal" claim is present, then the second mechanism has been selected by the client.

The mechanisms are independent from the other claims of the Client Attestation PoP JWT, e.g., independent from the applicable "exp" claim or from the "jti" claim. The memory requirements on the client side and on the server side are much lower than in the previous description. The same principles can be used in the context of replay detection betwen a client and a server by using only claims that are necessary to detect replays.

Many other changes would be required, in particular in the text from section 8 and in the definitions of the claims.