Wallet Attestations and Nonces

[tlodderstedt]

Currently, implementations can protect the PoP for wallet attestations (https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth) by:

• making it short lived
• making it one time use
• binding it to a protocol artifact like the authorization code (as kind of a nonce)

The latter does not work for Pushed Authorization Requests.
The proposal was made, to let the wallet request a nonce from the Issuer that can then be used for binding the wallet attestation. This came up in various discussions including the eIDAS expert group's touch point meeting on OID4VCI and discussions with member states.

The basic idea would be to define another endpoint, e.g. nonce endpoint, the wallet could be use to obtain that nonce.

[peppelinux]

why not reducing complexity by signing the request (request) with the private key where the public one is attested within the WIA (client_assertion)?

I believe we can satisfy all the requirements without adding anything new and preserving the current implementations

POST /as/par HTTP/1.1
Host: pid-provider.example.org
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=$thumprint-of-the-jwk-in-the-cnf-wallet-attestation$
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256
&request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KIC Jpc3MiOiAiczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQo gInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNkJoZFJrcXQz IiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1...
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation
&client_assertion=$WalletInstanceAttestation$

[tlodderstedt]

@peppelinux You mean the signature over the request is the proof of possession for the wallet attestation? That would mean to send a signed request object to the PAR endpoint, right? Something like this:

`POST /as/par HTTP/1.1
Host: pid-provider.example.org
Content-Type: application/x-www-form-urlencoded

response_type=code
&client_id=$thumprint-of-the-jwk-in-the-cnf-wallet-attestation$
&request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KIC Jpc3MiOiAiczZCaGRSa3F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQo gInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNkJoZFJrcXQz IiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1...

That would reduce the attack surface as an attacker would need to replay the request. It does not work (out of the box) for token requests as there is no equivalent of a signed request there.

[fmarino-ipzs]

The token request can be bound to the authorization code. Regarding the client authentication, both private_key_jwt or draft-looker-oauth-attestation-based-client-auth might be used. @tlodderstedt do you see any issues on this?

[peppelinux]

That would reduce the attack surface as an attacker would need to replay the request. It does not work (out of the box) for token requests as there is no equivalent of a signed request there.

I assume that a jti within the JWT (signed) request avoids the possibility that issA+jti may collide with issB+jti or be used in a replay attack.

following this assumption, may we say that nonce is then not required anymore?

[tlodderstedt]

@peppelinux As I wrote in my initial comment, one time use (jti) is a possible option for replay prevention. However, one time use limits scalability and nonces offer more implementation flexibility and are considered best practice.

@fmarino-ipzs As I wrote in my initial comment, an authorization code cannot be used as nonce in a pushed authorization request. So we either stick to one time use or short expiration or we add support for nonces.

[peppelinux]

adding a new endpoint for satisfying the same requirement satisfied by jti, according to RFC, might sound overkill

[fmarino-ipzs]

My comment was related to your last sentence regarding the token request where there is no equivalent to the signed request. For the PAR, the jti approach provides the same benefit in term of replay attack without introducing a new endpoint.

[tlodderstedt]

@peppelinux Can you please describe why you assess use of a nonce as "overkill"?

As I already stated, jti requires one time use on the issuer side, which means shared, current state across cluster nodes. This is know to cause issues with scalability of systems. Besides this, nonces provided by the receiving party are best security practice.

[tlodderstedt]

@fmarino-ipzs

My comment was related to your last sentence regarding the token request where there is no equivalent to the signed request.

@peppelinux suggested to use a request signature as proof of possesion instead of the proof of possession in the wallet attestation pop. That would work for PAR but not for the token request, as there is no signed token request. So the question is whether the proof of possession is implemented as defined in draft-looker-oauth-attestation-based-client-auth (as JWT appended to the assertion) or as another private_key_jwt parameter. Not sure of the benefits of the later.

For the PAR, the jti approach provides the same benefit in term of replay attack without introducing a new endpoint.

I disagree. Please read my comment above.

[fmarino-ipzs]

From a security point of view (mitigation against replay attacks), I see no benefit in using a nonce over jti. On the contrary, using a nonce requires a new endpoint that does not come for free. But maybe I am missing something. Regarding the scalability issue, which has nothing to do with security or even PoP, could you give us some references?

[peppelinux]

My intent is to reuse what we already have without require any additional endpoints made for the issuance like the nonce endpoint might represent.

I look forward to the satisfaction of the security requirements with their implementation considerations, putting aside every personal taste, as an implementer, and above all the ideas to which we try to become attached.

Here I share the flow that a group of developers and analysts have implemented and tested on stage, which uses both PAR and token endpoint with DPoP. We continue working on that, then our approach is still open. Since this beautiful working group is enriched by mutual experiences it will produce for sure a solution that objectively move, replace or improves, in our minds, the flow that is shared below:

https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/pid-eaa-issuance.html#token-endpoint

I believe that for the value of decision making, it is important to highlight why some choices are preferable to others, then we will implement them exactly like Buddhist monks destroy their sand mandalas for creating new ones (without getting attached!).

In the previous flow the private_key_jwt is involved, the signed JWT contains aud, exp and jti. Then sub, aud and jti prevents the replay.

Probably you're trying to tell us that using the nonce endpoint it would give the benefit to reduce the cross checks above multiple JWS, HTTP Headers and HTTP parameters? If yes let's try to have a clear schema about the number of checks and the attested level of security given by these, then we'll definitively feel comfortable to adopting a solution instead of another

[peppelinux]

@peppelinux Can you please describe why you assess use of a nonce as "overkill"?

As I already stated, jti requires one time use on the issuer side, which means shared, current state across cluster nodes. This is know to cause issues with scalability of systems. Besides this, nonces provided by the receiving party are best security practice.

I think that this really needs to be confirmed with objective elements (since this chat of nonce vs. jti is long from more than a year, you know 😅)

with the cap of implementer I assume to have a cluster of services, be they whatever entity that deals with JWTs and serves the token endpoint.

I require that a centralized or distributed storage is then used, where any transactions life time happen: creation, enrichment/update and pruning.

If I have a nonce endpoint, when I issue a nonce this would be stored in the storage shared between the nodes. This would be the same for any transaction or couple of iss-jwt (unique-together) -> stored in the storage, be it a nonce or a couple of issuer-jti.

There are other cases where the nonce is encrypted with a key that is know within the cluster, this doesn't require a storage, because any receiving party would validate by decrypting it (as some strategy does with the web cookies, for instance).

anyway, due to the important number of mixed endpoints we used to have in the OAuth2 framework, we know that anyway we need a layer of persistence where the transaction is tracked and enriched/updated. Then I don't see these scalability improvements or concerns of a solution vs another.

@tlodderstedt or @jogu, since you worked for decades in IETF and with success with all-about-nonce, could you please enlights why the nonce is a game changer in this context and the jti must then not be used?

[jogu]

The key differences with jti vs nonce:

nonce is generated by the authorization server and it doesn't actually necessarily need to store anything (sometimes it generates a hash or jwt in some fashion that means it can verify a value without needing to have stored it, or values can be communicated in advance to all servers).

jti is generated by the client. Many authorization servers don't check jti uniqueness (it's not mandatory to implement in most specs). Checking jti properly definitely requires a store that is shared across all regions the token can be presented in. The size of the store varies depends on the validity time of the token, which is also set by the client (iat/exp) in many cases, and the size is potentially unbounded depending on how fast clients might present valid tokens. Because the jti is client selected, if a client is compromised in some way the attacker can generate valid jwts for use (potentially days) later (nonces prevent that).