Re: [Rats] Removal of the "replay protection and privacy" section in the EAT draft

[Giridhar Mandyam <[e-mail]>]

> The text above talks about two mechanisms, namely
>- nonces, and
>- the cti/jti.
> In the EAT draft version -14 the cti/jti claims are mentioned in two sections, namely in Section 8.4 (see above) and also in Section 4.3.1. The cti claim contains a unique identifier for the JWT.

Actually all mention of cti/jti has been removed in this section and the rest of the document as of recent PR merge.  See https://github.com/ietf-rats-wg/eat/pull/308.  EAT spec is now silent on the use of cti/jti.

I do think there is room for cti as the sole replay protection in an EAT token when a nonce is not possible (i.e. one-way transport such as IP Multicast/BLE-AD), but it appears that group consensus is to not discuss it as a replay mechanism in the document itself.  EAT does not prevent an implementor from using an existing CWT/JWT claim so cti could appear in an EAT token.

> The privacy implications of the nonce are not described nor are other privacy implications of the iat (issued at) claim defined, which would correspond to the timestamp replay protection mechanism defined in the RATS architecture.

That is not my interpretation of the current text.  The text only discusses the privacy implications of the nonce.

Moreover, iat is a claim whose value is set by the token issuer.  Nonce presumably is not.  For claims set by the token issuer, the attester could (depending on the implementation) take user privacy preferences into account when determining which claims to include.  As a crude example, if an entity's permissions settings indicate that location should not be exposed by the device to any 3rd-parties then the location claim could be excluded by the attester.  Therefore the privacy considerations for the 2 claims are different.

There could be a privacy considerations sub-section for token-issuer controlled claims, but I think such considerations would not be particularly meaningful without assuming certain implementations (e.g. Android/Windows permissions framework and how it affects claims included in the token).  This might have been the reason why RFC 8392 avoided such a discussion altogether (https://datatracker.ietf.org/doc/rfc8392/).

-Giri

-----Original Message-----
From: RATS <[e-mail]> On Behalf Of Hannes Tschofenig
Sent: Thursday, September 29, 2022 4:37 AM
To: [e-mail]
Subject: [Rats] Removal of the "replay protection and privacy" section in the EAT draft

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi all,

In PR https://github.com/ietf-rats-wg/eat/pull/299 I proposed a re-write of the privacy consideration section.

As part of my re-write I removed text that was, according to Giri, "reviewed and agreed upon by the Architecture team and EATS editors in https://github.com/ietf-rats-wg/eat/pull/164".

Now, I would like to bring it to the group. Here is the relevant text:

8.4.  Replay Protection and Privacy

   EAT offers 2 primary mechanisms for token replay protection (also
   sometimes known as token "freshness"): the cti/jti claim and the
   nonce claim.  The cti/jti claim in a CWT/JWT is a field that may be
   optionally included in the EAT and is in general derived on the same
   device in which the entity is instantiated.  The nonce claim is based
   on a value that is usually derived remotely (outside of the entity).
   These claims can be used to extract and convey personally-identifying
   information either inadvertently or by intention.  For instance, an
   implementor may choose a cti that is equivalent to a username
   associated with the device (e.g., account login).  If the token is
   inspected by a 3rd-party then this information could be used to
   identify the source of the token or an account associated with the
   token (e.g., if the account name is used to derive the nonce).  In
   order to avoid the conveyance of privacy-related information in
   either the cti/jti or nonce claims, these fields should be derived
   using a salt that originates from a true and reliable random number
   generator or any other source of randomness that would still meet the
   target system requirements for replay protection.

The RATS architecture talks about three approaches for providing freshness, namely
- timestamps,
- nonces, and
- epoch IDs.

The text above talks about two mechanisms, namely
- nonces, and
- the cti/jti.

(As you will see later, the cti/jti does not correspond to one of the freshness mechanisms from the RATS architecture.)

In the EAT draft version -14 the cti/jti claims are mentioned in two sections, namely in Section 8.4 (see above) and also in Section 4.3.1. The cti claim contains a unique identifier for the JWT.

Assuming that an implementer uses the cti to convey a username / account login is unjustified given what Section 4.1.7 of RFC 7519 defines it to be, see  https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7.

So, there is only a privacy problem with the cti/jti if you use it in a way that has not been envisioned and even suggested by the RFC that defined it.

The privacy implications of the nonce are not described nor are other privacy implications of the iat (issued at) claim defined, which would correspond to the timestamp replay protection mechanism defined in the RATS architecture.

For this reason I suggested to remove this text from the privacy consideration section.

Ciao
Hannes



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
RATS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rats