On Fri, Apr 25, 2025 at 5:49 AM Denis <denis.i...@free.fr> wrote: > > Hi Christian and Watson, > > Hi Watson, > > > > Sorry for the late response. I would fully agree that challenge would be the > better term here and there is a bit of ambiguity for the term nonce in OAuth > imho. > > +1 Yes, for a nonce sent by the authorization server, the term "challenge" > would be a better term. > > > While a nonce generally speaking would usually mean a random input, in the > context of OAuth, it is afaik interpreted as an opaque challenge that should > be sufficiently random (so it cannot be guessed). > A nonce in this context could just be a server-signed/HMACed JWT containing > things like the server time when the nonce was generated for which the term > challenge would probably be a better fit > - If I recall correctly, that behaviour/usage is also explained in the DPoP > spec. > > > See current IANA definition: > > 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) > > The IANA definition of the claim nonce is rather vague and in an client- > server paradigm, does not say > whether the nonce is generated by the client or by the server . > > The current draft is using the term "nonce" when it is generated by the > (authorization) server. > > In general, two mechanisms are able to *detect* replay attacks: > > - either using "unique numbers" that are generated and sent by a client > to a server, > - or using "challenges" that are generated and sent by a server to a > client. > > Using "unique numbers" does not require any Preflight request, but for > practical implementation reasons, > mandates the use of a local clock loosely synchronized with UTC. In practice, > a "unique number" will be composed > of the iat claim and of a random number (rnd claim). This eliminates the need > of a *challenge* fetching mechanism > for Attestation-Based Client Authentication.
These mechanisms do not have the same properties. A challenge shows liveness, a unique number does not. A unique number has all the deployment issues I identified in my earlier message. A timestamp bypasses some of the issues with a challenge, but requires synchronization. It's also replayable unless we say it's also unique, and that's very hard to assure at scale. That's not the same as liveness, and blocking replays interacts badly with cases where requests might be automatically retried. > > Using "challenges" mandates to previously obtain a challenge from the server > which means a Preflight request. > This mandates the need of a *challenge* fetching mechanism for > Attestation-Based Client Authentication and > thus mandates to identify an end-point to request it. > > The question are now as follows: should this document describe: > > 1) a replay detection mechanism using only "unique numbers" ? > 2) a replay detection mechanism using only "challenges" ? > 3) a replay detection mechanism using either "unique numbers" or "challenges" > ? It is very important that a unique number cannot be understood as a challenge. > > In the context of SD-JWT, I have posted a full description of these two > replay detection methods in: > https://mailarchive.ietf.org/arch/msg/oauth/JEk5Jtyw2G042LFRA5-r0J9i2EI/ > See comment 6 under the topic of REPLAY DETECTION OF a **Key Binding JWT**. > > Best regards, > > Denis > > > > Best Regards, > > Christian > > > > From: Watson Ladd <watsonbl...@gmail.com> > Date: Sunday, 6. April 2025 at 02:27 > To: Christian Bormann <chris.borm...@gmx.de> > Cc: oauth <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Nonce fetching mechanism for Attestation-Based Client > Authentication > > > > 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 > > The client discovers via metadata that the PAR endpoint requires > attestation-based client authentication with a nonce > The client sends an OPTIONS request: > > OPTIONS /as/par HTTP/1.1 > > Host: as.example.com > > attestation-nonce-request: true > > The client receives a nonce in the response: > > HTTP/1.1 200 OK > > Host: as.example.com > > attestation-nonce: AYjcyMzY3ZDhiNmJkNTZ > > 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 > > 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%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 to oauth-le...@ietf.org > > -- Astra mortemque praestare gradatim _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
