Since Christian raised an issue on github 5 days ago, I have provided a
detailed response at:
https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/104
I took a quick look at: draft-demarco-oauth-nonce-endpoint-00
*"Nonce*:
A random or pseudo-random number that is generated for a specific
use, typically for cryptographic communication.
The Nonce is used to *protect* against replay attacks by ensuring
that a message or data cannot be reused or retransmitted.
The term "Nonce" stands for "number used once" and it MUST be unique
within some scope."
A message or data CAN be reused or retransmitted, but this can be DETECTED.
*"Nonce Issuer*:
The entity that generates and provides the Nonce. In the context of
OAuth 2.0, the Nonce Issuer would typically be the Authorization
Server".
This is not a correct approach. There exist two mechanisms that are
using two different sets of terminology which are able to *detect*
replay attacks:
* one can be implemented using 3 exchanges (where a challenge is
generated by the server)
* the other one can be implemented using 2 exchanges (where a unique
number is generated by the client).
If the client supports a UTC clock then the "unique number" mechanism
can be used, whereas the challenge mechanism can always be used.
Note: It is assumed that the server always supports a UTC clock.
If correctly described and implemented, both mechanisms offer the same
level of detection.
The type of *detection* mechanism that can be used is independent from
the fact that the server is an Authorisation Server or any other kind of
server.
"The *Nonce Issuer* MUST satisfy the following requirements:
-Generate a unique Nonce for each request to ensure the Nonce Issuer
*never *produces identical Nonces,
regardless of whether they occur simultaneously or at different
times;
Encrypt the Nonce with an encryption key (...)"
This is incorrect. The uniqueness of the nonce is not for a life-time
but only within a time-frame and within a context.
In practice, a "unique number" is composed of a UTC time and of a random
number as this simplifies implementations.
There is no need to use any kind of encryption key.
"When an Authorization Server requires the use of a Nonce in the
request for a specific resource and the Client does not provide it
in its request,
the Authorization Server MUST return an HTTP response with the HTTP
status code |400|and an |error|field with the value set to
|"nonce_required"|."
This is incorrect. In general, the server should be able to support both
the challenge method and the unique number method.
"The robustness of the encryption key plays a crucial role in the
security of the Nonce Endpoint"
There is no need to use any kind of encryption key.
Section 10 of draft-demarco-oauth-nonce-endpoint-00 acknowledges the
fact that using the jti claim to *detect* replays is not the best solution.
Please take a look at my detained explanations at
https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/104
Denis
On Sat, Apr 5, 2025, 8:17 AM Christian Bormann
<chris.bormann=40gmx...@dmarc.ietf.org> wrote:
Hi All,
We had a discussion about a nonce fetching mechanism for the
Attestation-Based Client Authentication draft at the
IETF 122 session. Since we didn’t really reach a consensus there,
we’d like to continue the discussion on the mailing list.
I alas haven't had a chance to watch all the discussion even now so
forgive me if I'm being redundant. What you want is not a nonce for a
few reasons:
1:nonces can be predictable. Ideally we'd bind the proof of possession
to the one who needs it to prevent an attacker relaying the request or
issuing one for the same predicted value.
2: we probably want some degree of licenses
3: counting is hard in big systems
All of this makes me think we just want to sign a server provided
challenge with some rules on construction rather than specifically a
nonce.
To summarize the problem briefly: The draft specifies a proof of
possession that optionally signs over a server-provided
nonce to guarantee freshness of said proof of possession. Since we
expect this specification to be used in some contexts
where creating a PoP might be expensive (e.g., require a user
interaction), we were searching for a mechanism where
the nonce is not provided via an error (as is the case for DPoP -
which would often require the generation of 2 PoPs),
but in a way that guarantees that we have a fresh nonce before
creating a PoP.
We were thinking about either
* a dedicated nonce endpoint (within the scope of an AS or RS)
* or a mechanism to explicitly ask for a nonce in a request to
an existing OAuth endpoint (e.g., the PAR endpoint).
After some discussion at OAuth Security Workshop, we proposed to
use a dedicated header to signal a request for a new
nonce. This could work at any existing OAuth endpoint that wishes
to use an attestation-based client authentication. Brian
rightfully mentioned that only adding one header field and
completely changing the behaviour of said endpoint does not
sound like a good idea and proposed to use a different HTTP
method. Brian initially proposed HEAD and after some more
discussion we ended with an OPTIONS request as the seemingly best
idea.
The idea as currently document in the draft is to use an OPTIONS
request with a specific header field to request a nonce.
The current proposal would mean that for a request to a PAR endpoint
1. The client discovers via metadata that the PAR endpoint
requires attestation-based client authentication with a nonce
2. The client sends an OPTIONS request:
OPTIONS /as/par HTTP/1.1
Host: as.example.com <http://as.example.com>
attestation-nonce-request: true
3. The client receives a nonce in the response:
HTTP/1.1 200 OK
Host: as.example.com <http://as.example.com>
attestation-nonce: AYjcyMzY3ZDhiNmJkNTZ
4. The client does the “real” request to the PAR endpoint
including the client authentication (via header fields):
POST /as/par HTTP/1.1
Host: as.example.com <http://as.example.com>
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC…
OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI…
response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org
<http://2Fclient.example.org>%2Fcb
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
&code_challenge_method=S256&scope=account-information
At the IETF 122 session, Filip voiced concerns that since OPTIONS
is used for CORS preflight requests, it would mean that at
least for frontend clients, this mechanism would result in several
OPTIONS requests. For JavaScript clients, the CORS preflight
requests cannot be used or modified and the client would then
manually create another OPTIONS request to get the nonce.
From a simple OPTIONS (preflight) and POST requests (normal
request to PAR), we would get to OPTIONS (preflight),
OPTIONS (nonce fetch), OPTIONS (preflight), POST requests.
We tried to capture those concerns in this issue:
https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/102
and would like to pick that discussion up again to find some
consensus what the best option would be to for a nonce request.
Would people be more comfortable if we instead point to an
endpoint that can be used to request a nonce (dedicated endpoint
that could for example, be discoverable via metadata), or is it
fine to cause more requests and we should move ahead with the
current variant based on OPTIONS?
Best Regards,
Christian, Paul, Tobias
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
