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

["Smith, Ned" <[e-mail]>]

The privacy considerations section should clearly describe that nonce reuse could result in privacy compromise.
-Ned

On 9/29/22, 8:16 AM, "RATS on behalf of Giridhar Mandyam" <[e-mail] on behalf of [e-mail]> wrote:

    > Why would anyone use a nonce to convey a username in it? Has anyone done this already?

    I hope not.  But nonce is a new CWT claim and we don't know how it is being used.  Use of username/password alone was meant to be an extreme example of how not to generate a nonce, but even a random value that is generated exactly one-time and is forever tied to the user account (i.e. continually re-used) could also impact privacy.  In this case, the nonce can serve as an identifier of the user account and therefore the user.

    The nonce privacy section in EAT was partly inspired by comparable considerations on challenge data (https://www.w3.org/TR/webauthn-2/#dom-collectedclientdata-challenge) from FIDO/Webauthn:  https://www.w3.org/TR/webauthn-2/#sctn-cryptographic-challenges.

    As you can see from the above, the normative description of challenge does not make any restrictions on use of solely deterministic data in determining the challenge. The security considerations section however makes it clear that the server-provided challenge must be generated from a reliable source of randomness.   The above cited text further goes on to say " This SHOULD be done in a fashion that does not rely upon a client's behavior", which means that a nonce  should not be generated one time only and used for subsequent operations for the given user (and the ensuing example implies as much when it says "the Relying Party SHOULD store the challenge temporarily until the operation is complete").  

    FIDO's mandate of nonce randomness on a per-operation level is treated solely as a security consideration.  In my opinion there is a privacy aspect as well, and FIDO might have been better served to expand upon the "does not rely upon a client's behavior" requirement as part of their privacy considerations.  

    -Giri

    -----Original Message-----
    From: RATS <[e-mail]> On Behalf Of Hannes Tschofenig
    Sent: Thursday, September 29, 2022 7:52 AM
    To: Giridhar Mandyam <[e-mail]>; [e-mail]
    Subject: Re: [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 Giri,

    Good to hear that the text about the cti/jti was removed.

    If I just look at the remaining text from the replay protection section (see below) then the content has obviously changed: instead of claiming that the cti contains an equivalent of a username or account login, it now says that the nonce may contain that information.

    Why would anyone use a nonce to convey a username in it? Has anyone done this already?

    Ciao
    Hannes

    ------

    Replay Protection and Privacy

    EAT defines the nonce claim for token replay protection (also sometimes known as token "freshness"). The nonce claim is based on a value that is usually derived remotely (outside of the entity). This claim can be used to extract and convey personally-identifying information either inadvertently or by intention. For instance, an implementor may choose a nonce 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. In order to avoid the conveyance of privacy-related information in the nonce claim, it 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.

    -----Original Message-----
    From: Giridhar Mandyam <[e-mail]>
    Sent: Thursday, September 29, 2022 4:07 PM
    To: Hannes Tschofenig <[e-mail]>; [e-mail]
    Subject: RE: Removal of the "replay protection and privacy" section in the EAT draft

    > 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
    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

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