Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?

John Bradley <ve7jtb@ve7jtb.com> Mon, 31 July 2017 14:01 UTC

Return-Path: <ve7jtb@ve7jtb.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 BC39E131D1D for <oauth@ietfa.amsl.com>; Mon, 31 Jul 2017 07:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ve7jtb-com.20150623.gappssmtp.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 cqclEI5NFi5Q for <oauth@ietfa.amsl.com>; Mon, 31 Jul 2017 07:01:15 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 247201275F4 for <oauth@ietf.org>; Mon, 31 Jul 2017 07:01:15 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id v29so88047606qtv.3 for <oauth@ietf.org>; Mon, 31 Jul 2017 07:01:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=coT4XV656fFDlg/KI7/JYq0DNYWvHf83Jol8wRtVp3w=; b=u9IWxx9P8NNh4NdCFvM4brwdQR3uedhYGYbnsQXlgALqrLcP8xVFApSGaTuerpn6hJ Vc5Q5TU1fB3D0UTHMIyXmBpV0zxyPxRa1ECmiG9oDtxoSotQgKMUzLZupCLuyZ/ZaLRf n+Zt8IttmTanjivUsXozf4sSAPk8UVrRREXg7rn/5wZoHlhf8T4vEflChe0SsLmttWhw ertSVloEpnZVhx9aAgq12toZJyj5boS2f4ob7wc+LQ9emyRMEb5jCv3HjBBUgQd8dlTj BxkIqfMCxxbCKVd41qf1JfMfMitv1Lf1o7Iuj1Y3x0bYQH1sGtTwIW/xakv+HDdePUcf ExEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=coT4XV656fFDlg/KI7/JYq0DNYWvHf83Jol8wRtVp3w=; b=Q3y7PXLFn0bbds1T0X1CO3NOUQ9+RwLfpFxgaE0Dotz7x6x4k8NHm8IwQKQjKv2nL2 lv10wZUqUqvic4kvI4PJy9uDcGULyH7pMwkORo4Jf9o1rGy0YncL6S1DB/0oklZxU9aG IdN+Q4Y50XEnJxPgkX502uG15SX3Hm1C2cCUt0Fustx5GDY4lSWbTSsiAZ4+ubtMnlS2 0msZhh0SrfCLN8Chx5rQN+bf+3fPAFDhXQMNVl9nUQKqJ6PhPtP4y5Zeh91tL9T2/2Et SeA3f3ixe1yqKZhBW4x0qzKwsu7EKceDK2O0YefGcRq1ltmIEWcb/PnDbNe4mLq5lUp3 s72g==
X-Gm-Message-State: AIVw113EiboH+J5ZcVQf47vgwSmg+RTDoGYwowE8UmBy9e6fLPzJgPrs gm/aRXUFZoos2BW5QtIxxg==
X-Received: by 10.200.39.212 with SMTP id x20mr22893095qtx.157.1501509672759; Mon, 31 Jul 2017 07:01:12 -0700 (PDT)
Received: from johns-mbp.lan ([191.115.5.74]) by smtp.gmail.com with ESMTPSA id f32sm22799313qkf.4.2017.07.31.07.01.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 07:01:11 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <46E8AB48-2DD1-4C1C-B8FA-0FBADAB7596F@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 31 Jul 2017 10:01:05 -0400
In-Reply-To: <e20207fc-804e-9485-7f18-736f423a0eeb@free.fr>
Cc: oauth <oauth@ietf.org>
To: Denis <denis.ietf@free.fr>
References: <e20207fc-804e-9485-7f18-736f423a0eeb@free.fr>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1135b542c4469b05559d762d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nwxFFed9zOnlXf9n9u0G7vtZO-U>
Subject: Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 31 Jul 2017 14:01:18 -0000

I think there may be some confusion between two different things that can use JWT.

In OAuth a client asks for authorization to access some API set of resources.  The AS is supposed to gather consent.
In principal to construct some reasonable dialog for the user to grant the consent and to be able to produce the correct format access token it is should know what the RS is.   

I need to be convinced that this is a real privacy issue.

It is also likely covered with token binding if it were a problem.

The other is Authentication in openID Connect.  This is using id_token JWT that are returned to the client.

In principal it may be desirable in some cases to hide the client from the AS.   That impacts client_id and redirect registration.  The aud is already the client_id so there is no new resource parameter for that.

How to do this securely for Connect is a big question.

For access tokens I would like to see a use case for a completely decoupled and anonymous RS that is not just a misuse of OAuth for Authentication, before trying to add a feature like this.

John B.


> On Jul 31, 2017, at 3:27 AM, Denis <denis.ietf@free.fr>; wrote:
> 
> This is a follow-up of the OAuth workshop held in Zurich on July 13 th.
> 
> At the end of the first day, Sven Hammann made a presentation on the following topic: 
> "A private mode for OpenID Connect"
> 
> Slide 14 indicated the motivation of the presentation :
> 
> The IdP learns at which Relying Parties (RPs) the user logs in
> This does not respect the user's privacy
> User's activities over multiple RPs can be tracked
> User might not want anyone to know which service they are using
> Especially if using the RP might provide sensitive information
> I Alcoholics Anonymous
> I Medical Forums
>  Slide 22 indicated:
> 
> Privacy and Security Goals
> Privacy towards IdP: IdP cannot distinguish between logins to different RPs.
> 
>  Slides 33 indicated the problem to be solved (hence the title of this email):
> 
> How can the IdP create an id token for one audience RP without knowing for which RP?
>  
> In the previous presentation from John Bradley and Torsten Lodderstedt (Access token phishing), 
> made on the same day, the same problem was considered with the final slide asking: " What do you think ? "
> 
> I believe that it is the time to agree on a solution for this problem.
> 
> As I already said on the WG list, the audience parameter does not allow to respect privacy. 
> However, there are cases where both an access token MUST be targeted and privacy MUST be supported.
> 
> Draft "JSON Web Token Best Current Practices" recently became draft-ietf-oauth-jwt-bcp-00. 
> One major problem (with respect to privacy) is that it mandates the use of the audience parameter:
> 
> 3.8.  Use and Validate Audience
> If the same issuer can issue JWTs that are intended for use by more than one relying party or application, 
> the JWT MUST contain an "aud"(audience) claim that can be used to determine whether the JWT is being 
> used by an intended party or was substituted by an attacker at an unintended party.
> With such a wording, as soon as the "aud" claim will be used, privacy will be violated since the AS will be able 
> to act as Big Brother.
> 
> Similarly, in a token request the use of the OPTIONAL resource parameter is also violating privacy : it indicates 
> the physical location of the target service or resource where the client intends to use the requested security token. 
> The value of the "resource" parameter MUST be an absolute URI, as specified by Section 4.3 of [RFC3986],
> 
> During the workshop, it has been proposed to use some signature on some data placed outside the access token.
> I propose a different approach where both a new parameter placed inside the access token will be used and 
> a new structure placed outside the access token will be used. This means :
> 
> -          the addition of a tid (target identifier) parameter inside the access token, and
> -          the definition of a new data structure placed outside the access token (which does not require the computation 
>  of a digital signature and does not require the demonstration of a proof of possession of a key).
> 
> Once the basic principles have been explained, let us now explain how the mechanism would work.
> The client chooses the URI of the target service. For every access token request (and for every target service, see later on 
> the case of multiple targets), it generates a random number (rdn). It then computes tid = OWHF (rdn, URI) where the rdn 
> comes first and where the URI comes after. OWHF is a One Way Hash Function.
> 
> The client communicates to the Authorisation Server a method which includes two parameters: the OID of the OWHF to be used 
> (e.g. SHA 256) and the value of tid that it has computed. The AS blindly copies and pastes this information into the access         token.
> 
> The client communicates to the Target Server (outside the access token): the method, the OID of the OWHF, the value of the rdn 
> and the value for the URI.
> 
> The Target Server first verifies that the data structure placed outside the access token matches with the data placed inside 
> the access token: same method and same OID for the OWHF. Then after, it verifies that the URI (placed outside the access token) 
> matches with one of the expected values and then using the method, the designated OID of the OWHF, the received rdn and 
> the received URI computes OWHF (rdn, URI). It finally verifies that the result of this computation is identical to the tid parameter 
> contained in the access token. If the verification is successful, the access token is accepted by the Target Server, otherwise it is rejected.
> 
> Note that an access token MAY include several target identifiers. This should be used with care since such an access token might be usable 
> by one designated Target Server towards another designated Target Server. However, there are circumstances where this is a desirable feature.
> As indicated earlier, each target identifier (tid) is computed using a different rdn.
> 
> Comments ?
> 
> Denis
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth