Re-written Privacy Considerations

[hannestschofenig]

I changed the privacy consideration section.

[gmandyam]

This proposed PR removes a section on replay protection and privacy that was reviewed and agreed upon by the Architecture team and EATS editors: see #164.

[hannestschofenig]

The text about replay protection has little to no implementation for privacy and is misplaced in the document.

[gmandyam]

The text about replay protection has little to no implementation for privacy and is misplaced in the document.

Would recommend you take your concerns back to the RATS arch. team who requested this text and reviewed it before it was merged.

Also I did not find this issue raised in the iotdir LC review (https://mailarchive.ietf.org/arch/msg/rats/zubR3clEkOwh68bPvwbD8NPwY2k/) nor secdir LC review (https://mailarchive.ietf.org/arch/msg/secdir/pHag-WP-Zkqo-Yvzv_RdXDfSGsM/).

[hannestschofenig]

Good idea, Giri.

[hannestschofenig]

Here is what I posted to the RATS list:

In PR #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.

[gmandyam]

This PR is not really applicable given the changes that came in after -14. If there are suggested changes to the nonce considerations in either the Privacy or Security cons sections then please propose them to the WG to obtain consensus.

[henkbirkholz]

@hannestschofenig is there anything left anything unaddressed here?