are there any special privacy issues around the nonce claim?

[mcr]

The challenger could inject identifying information into the nonce claim.
Do you need to say something specific about this?

[dthaler]

I think this discussion belongs in the document that defines the nonce claim (EAT) not the arch doc per se. Same for any other specific claims that might have similar issues.

[gmandyam]

I think this discussion belongs in the document that defines the nonce claim (EAT) not the arch doc per se. Same for any other specific claims that might have similar issues.

I think if a discussion regarding privacy for replay protection mechanisms is required, then all documents that EAT inherits from should address this. EAT already inherits the jti/cti claims from RFC 7519/8392 respectively. There is no specific privacy discussion in those documents regarding these claims. Moreover, the cti/jti claims can be client-originated (potentially internal to entity) and can certainly be used for extraction of PII by bad actors, while a nonce is expected to be verifier-generated (i.e. external to entity).

In short, a privacy discussion should cover all anti-replay mechanisms that are possible with CWT/JWT's, not just the claims introduced in EAT. In that regards, the EAT document may not be the best place for this discussion. Nevertheless I have made a first attempt: see ietf-rats-wg/eat#164.

[thomas-fossati]

I think this discussion belongs in the document that defines the nonce claim (EAT) not the arch doc per se. Same for any other specific claims that might have similar issues.

The reason I brought the issue here is that the nonce is introduced in Section 10.2 of the architecture and since all RATS documents are supposed to inherit from here, it sounded like a good place to discuss the point once and let downstream docs reference it as many times as needed.

Another convenient place where the privacy discussion can be factored out could be Section 7.1 of the interaction models.

BTW, I have raised a related issue in the DAA repo.

[mcr]

https://github.com/ietf-rats-wg/eat/pull/164/files

[mcr]

Discussion of attack in call:

If a Verifier includes the IP address of the Attester in the nonce used for freshness challenge, encrypted, then it will appear to the Attester and possibly some audit process that no PII was leaked. However, if the symmetric key used for generated this nonce is later made available to some uber-observer, that they could then pull the PII (IP address) out of the audit trail.

DAA/reference-interaction-model could deal with the scenario where the Attester is suspicious of the Verifier.
Consensus that this does not require changes to the document.