Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?

Filip Skokan <panva.ip@gmail.com> Tue, 11 August 2020 15:32 UTC

Return-Path: <panva.ip@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0733A1108 for <oauth@ietfa.amsl.com>; Tue, 11 Aug 2020 08:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5u-MN_rNeG4 for <oauth@ietfa.amsl.com>; Tue, 11 Aug 2020 08:32:24 -0700 (PDT)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C013A1105 for <oauth@ietf.org>; Tue, 11 Aug 2020 08:32:24 -0700 (PDT)
Received: by mail-yb1-xb2f.google.com with SMTP id e187so7262960ybc.5 for <oauth@ietf.org>; Tue, 11 Aug 2020 08:32:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D9tnfs0pwx9s3wO6gm9XotxXsofN9NFex0KKUbuNspY=; b=sQ9J/v51zswl631WneLyHNaktxwBx8eeZoYDUZS30+coqzV6FfJVD4Ld2z05o5MGLM KOtplHDdQANBRKAHATJM8Gw+vRvGMrKKKm3SfoKZxlUQ9sryQc/xjbkQu3O2ScWpFbaB q8lJbr40Oe78+OhzFSFXluffZHQF9ZxDZ9aeD5S+bsAaZQivlV78M/a3fZmdjcVju0IU GjA6hYazCKNzaP2BMKC7PaCIBOcDdNvcSN/ZugebfxvVZ8CuZIawhbwUxycZYidM6y0N kRvcrUA2quCPRc0LWJ1dgX6gfW4vfccJSOsiKknnS/HG0KOvQDx4Ha3Xj1Rh7usxUDrX FPbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D9tnfs0pwx9s3wO6gm9XotxXsofN9NFex0KKUbuNspY=; b=iPSTAdN5D5+gr5jBGgQsaU+zG4uR40yP7lFWK/MEpoB/xAedrUn4nukmT3y9+dyT70 fUOBzH5SXA0ryJirz1Bb1GWsbudI2h7MSybJLXU2U0AuwWVnqcyQVJOhY22Kf0ob26bT oyAEl0xvks6VIFYTjtq7lkc204hGz8QIlzppGeMSfjqR8CN2QrAmhhgKgWdWKDXkoICo Xov3n+zvoW4peIZsMw83QlKI6qjrqfwGL3qSCIb1QfO72cL3I+Ema9DSkY8KF3WsdUOP usvhT5wZ3sAcS86LTkHBMI1EN61Kej+bBWefdgoKNz7LUZqQIPsAtj1+MnLSXD/GHNOL UgBQ==
X-Gm-Message-State: AOAM530se8WMFkYax3TMwa8LZ7x46JgGvuiTCkOW5cFca4CbxLwc11+m UHE9ilTdjZ07/R0ynJMAbUaedmRyBpI7wA17S2aldDw=
X-Google-Smtp-Source: ABdhPJyJyKytVSdBvrGCdgfZ8+PY+/ZyM5YlKlbnwkxAvvsufb2GN2yhRgnEY+sjWkTnwO6ZVm8aidVoz4fh7zwWGKk=
X-Received: by 2002:a25:7007:: with SMTP id l7mr45907853ybc.85.1597159943278; Tue, 11 Aug 2020 08:32:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAGBSGjp1APwLDk4uy8o+qvk62ZCnOJ4w54xPd7QEX1s+ZMZzog@mail.gmail.com> <E1F8E4D3-79B9-4B44-B918-169ABFB3FA2C@gmail.com> <91699c07-5f82-e69e-191c-962daf06a115@free.fr>
In-Reply-To: <91699c07-5f82-e69e-191c-962daf06a115@free.fr>
From: Filip Skokan <panva.ip@gmail.com>
Date: Tue, 11 Aug 2020 17:31:46 +0200
Message-ID: <CALAqi_8SrnwwxKccncCoQopqZpZfi3xCw3uhBKFkZTwSBFNT4g@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Aaron Parecki <aaron@parecki.com>, OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001194e405ac9bc778"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/EjMe0tDvi9ZQ8iPePtRr8vaRC9c>
Subject: Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 15:32:27 -0000

Denis, PAR is arguably not the document that should retrofit OAuth 2.0 with
a full blown Privacy Consideration section. Now, do you find the draft
introduces anything new from a privacy perspective? Does the AS get
anything other than what it already does via the authorization_endpoint
today?

For the record i'm not arguing OAuth 2.0 should be without privacy
considerations, i'm just saying - if it did, or rather, regardless if it
does or doesn't - PAR does not expand on those in any way.

S pozdravem,
*Filip Skokan*


On Tue, 11 Aug 2020 at 17:17, Denis <denis.ietf@free.fr> wrote:

> Hi Filip,
>
> I don’t think there’s anything new introduced in PAR that would alter
> existing status quo of privacy consiserations.
> As such if privacy consideration was to be added for completeness it
> should be along the lines of “this document
> does not expand on or otherwise alter the privacy considerations” or
> “there are no new privacy considerations introduced by this document”.
>
> OAuth 2.0 (RFC 6749) had no Privacy considerations section as it was
> issued before RFC 6973 (Privacy Considerations for Internet Protocols)
> existed.
>
> I browsed through the RFCs published by this WG and the guidance provided
> in RFC 6973 has not really be used and followed.
>
> So adding no text to nearly zero text will not help that much. I believe
> that a Privacy considerations section will be added to the OAuth 2.1 draft.
> While doing that exercise, a shorter version of it could be included in
> PAR.
>
> Hereafter is my detailed analysis:
>
> RFC 6973 (Privacy Considerations for Internet Protocols) has been issued
> in July 2013. RFCs issued earlier to RFC 6973 do not include a Privacy
> Considerations section.
>
> This is the case for :
> -          RFC 6749 (The OAuth 2.0 Authorization Framework) -          RFC
> 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) -
> RFC 6755 (An IETF URN Sub-Namespace for OAuth) -          RFC 6819 (OAuth
> 2.0 Threat Model and Security Considerations) For RFCs issued after RFC
> 6973, six of them don't have a have a Privacy Considerations section. This
> is the case for:
> -          *RFC 7009 *(OAuth 2.0 Token Revocation) - *      RFC 7519*
> updated by RFC 8725 (JSON Web Token Best Current Practices) -          *RFC
> 7636* (Proof Key for Code Exchange by OAuth Public Clients) -          *RFC
> 8252 *(OAuth 2.0 for Native Apps) does not have a Privacy Considerations
> section -          *RFC 8414 *(OAuth 2.0 Authorization Server Metadata) -
> *RFC 8628* (OAuth 2.0 Device Authorization Grant) Eleven of them have a
> Privacy Considerations section. They are enumerated below, with a copy of
> these sections. -          *RFC 7521* (Assertion Framework for OAuth 2.0
> Client Authentication and Authorization Grants) 8.4.  Privacy
> Considerations An assertion may contain privacy-sensitive information
> and, to prevent disclosure of such information to unintended parties,
> should only be transmitted over encrypted channels, such as TLS.  In
> cases where it is desirable to prevent disclosure of
> certain information to the client, the assertion (or portions of it)
> should be encrypted to the authorization server. Deployments should
> determine the minimum amount of information necessary to complete the
> exchange and include only
> such information in the assertion.  In some cases, the Subject identifier
> can be a value representing an anonymous or pseudonymous
> user, as described in Section 6.3.1. -          *RFC 7522* (Security
> Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client
> Authentication and Authorization Grants 7. Privacy Considerations
>
> A SAML Assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties,
> should only be transmitted over encrypted channels, such as Transport Layer Security (TLS).  In cases where it is desirable to prevent
> disclosure of certain information to the client, the Subject and/or individual attributes of a SAML Assertion should be encrypted to the
> authorization server.
>
> Deployments should determine the minimum amount of information necessary to complete the exchange and include only that information
> in an Assertion (typically by limiting what information is included in an <AttributeStatement> or by omitting it altogether).  In some cases,
> the Subject can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1 <https://tools.ietf.org/html/rfc7522#section-6.3.1> of the OAuth Assertion Framework [RFC7521 <https://tools.ietf.org/html/rfc7521>].
>
> -          *RFC 7523 *JSON Web Token (JWT) Profile for OAuth 2.0 Client
> Authentication and Authorization Grants 7.  Privacy Considerations A JWT
> may contain privacy-sensitive information and, to prevent disclosure of
> such information to unintended parties, should only be transmitted
> over encrypted channels, such as Transport Layer Security (TLS).  In
> cases where it is desirable to prevent disclosure of certain information to
> the client,
> the JWT should be encrypted to the authorization server. Deployments
> should determine the minimum amount of information necessary to complete
> the exchange and include only such claims in the JWT.
> In some cases, the "sub" (subject) claim can be a value representing an
> anonymous or pseudonymous user, as described in Section 6.3.1 of
> the OAuth Assertion Framework [RFC7521]. -          *RFC 7591* (OAuth 2.0
> Dynamic Client Registration Protocol) 6.  Privacy Considerations As the
> protocol described in this specification deals almost exclusively with
> information about software and not people, there are very few
> privacy concerns for its use.  The notable exception is the "contacts"
> field as defined in Section 2, which contains contact information for
> the developers or other parties responsible for the client software.  These
> values are intended to be displayed to end- users and will be available
> to the administrators of the authorization server.  As such, the
> developer may wish to provide an email address or other contact information
> expressly
> dedicated to the purpose of supporting the client instead of using their
> personal or professional addresses.  Alternatively, the developer may
> wish
> to provide a collective email address for the client to allow for
> continuing contact and support of the client software after the developer
> moves on and
> someone else takes over that responsibility. In general, the metadata for
> a client, such as the client name and software identifier, are common
> across all instances of a piece of client software
> and therefore pose no privacy issues for end-users. Client identifiers, on
> the other hand, are often unique to a specific instance of a client.
> For clients such as web sites that are used by many users, there may not
> be significant privacy concerns regarding the client identifier, but for
> clients
> such as native applications that are installed on a single end-user's
> device, the client identifier could be uniquely tracked during OAuth 2.0
> transactions
> and its use tied to that single end-user.  However, as the client
> software still needs to be authorized by a resource owner through an OAuth
> 2.0
> authorization grant, this type of tracking can occur whether or not the
> client identifier is unique by correlating the authenticated resource owner
> with
> the requesting client identifier. Note that clients are forbidden by this
> specification from creating their own client identifier.  If the client
> were able to do so, an individual client instance
> could be tracked across multiple colluding authorization servers, leading
> to privacy and security issues. Additionally, client identifiers are
> generally issued
> uniquely per registration request, even for the same instance of software.
> In this way, an application could marginally improve privacy by
> registering
> multiple times and appearing to be completely separate applications.  However,
> this technique does incur significant usability cost in the form of
> requiring
> multiple authorizations per resource owner and is therefore unlikely to be
> used in practice. -          *RFC 7592* (OAuth 2.0 Dynamic Client
> Registration Management Protocol) 6.  Privacy Considerations This
> specification poses no additional privacy considerations beyond those
> described in the core "OAuth 2.0 Dynamic Client Registration Protocol"
> [RFC7591]. -          *RFC 7662 *(OAuth 2.0 Token Introspection) 5.  Privacy
> Considerations The introspection response may contain privacy-sensitive
> information such as user identifiers for resource owners.  When this is
> the case,
> measures MUST be taken to prevent disclosure of this information to
> unintended parties.  One method is to transmit user identifiers as opaque
> service-specific
> strings, potentially returning different identifiers to each protected
> resource. If the protected resource sends additional information about
> the client's request to the authorization server (such as the client's IP
> address) using an extension
> of this specification, such information could have additional privacy
> considerations that the extension should detail.  However, the nature and
> implications of such
> extensions are outside the scope of this specification. Omitting
> privacy-sensitive information from an introspection response is the
> simplest way of minimizing privacy issues. -          *RFC 7800*
> (Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) 5.  Privacy
> Considerations A proof-of-possession key can be used as a correlation
> handle if the same key is used with multiple parties.  Thus, for privacy
> reasons, it is recommended
> that different proof-of-possession keys be used when interacting with
> different parties. -          *RFC 8176* (Authentication Method Reference
> Values) 4.  Privacy Considerations The list of "amr" claim values
> returned in an ID Token reveals information about the way that the end user
> authenticated to the identity provider.
> In some cases, this information may have privacy implications. While this
> specification defines identifiers for particular kinds of credentials, it
> does not define how these credentials are stored or protected.
> For instance, ensuring the security and privacy of biometric credentials
> that are referenced by some of the defined Authentication Method Reference
> values is beyond the scope of this specification. -          *RFC 8693*
> (OAuth 2.0 Token Exchange) 6.  Privacy Considerations Tokens employed in
> the context of the functionality described herein may contain
> privacy-sensitive information and, to prevent disclosure
> of such information to unintended parties, MUST only be transmitted over
> encrypted channels, such as Transport Layer Security (TLS).
> In cases where it is desirable to prevent disclosure of certain
> information to the client, the token MUST be encrypted to its intended
> recipient.
> Deployments SHOULD determine the minimally necessary amount of data and
> only include such information in issued tokens.  In some cases,
> data minimization may include representing only an anonymous or
> pseudonymous user. -          *RFC 8705* (OAuth 2.0 Mutual-TLS Client
> Authentication and Certificate-Bound Access Tokens) 8.  Privacy
> Considerations In TLS versions prior to 1.3, the client's certificate is
> sent unencrypted in the initial handshake and can potentially be used by
> third parties
> to monitor, track, and correlate client activity.  This is likely of
> little concern for clients that act on behalf of a significant number of
> end users
> because individual user activity will not be discernible amidst the client
> activity as a whole.  However, clients that act on behalf of a single end
> user,
> such as a native application on a mobile device, should use TLS version
> 1.3 whenever possible or consider the potential privacy implications of
> using mutual TLS on earlier versions. -          *RFC 8707* (Resource
> Indicators for OAuth 2.0) 4.  Privacy Considerations In typical OAuth
> deployments the authorization sever is in a position to observe and track a
> significant amount of user and client behavior.
> It is largely just inherent to the nature of OAuth, and this document does
> little to affect that.  In some cases, however, such as when access token
> introspection is not being used, use of the resource parameter defined
> herein may allow for tracking behavior at a somewhat more granular
> and specific level than would otherwise be possible in its absence.
>
> Denis
>
>
>
>
> Filip
>
> Odesláno z iPhonu
>
> 10. 8. 2020 v 19:21, Aaron Parecki <aaron@parecki.com> <aaron@parecki.com>
> :
>
> 
> I agree that there is nothing unique to PAR that would justify adding the
> privacy considerations mentioned to that draft. I wouldn't oppose adding a
> privacy considerations section to OAuth 2.1 though.
>
> Aaron
>
>
> On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt <dick.hardt@gmail.com> wrote:
>
>> In the PAR meeting today, Denis requested there be a privacy
>> considerations section in PAR. I don't think there is anything specific in
>> PAR that would change the privacy considerations of OAuth, and am checking
>> if there is WG interest, and consensus, on including a Privacy
>> Considerations section in the OAuth 2.1 draft.
>>
>> /Dick
>> ᐧ
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>