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

[Hannes Tschofenig <[e-mail]>]

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.