Return-Path: 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 A86901200E7 for ; Fri, 27 Dec 2019 14:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GHrQ-6ePoVaM for ; Fri, 27 Dec 2019 14:27:17 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 B8B8C1200DB for ; Fri, 27 Dec 2019 14:27:16 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id t2so27371937wrr.1 for ; Fri, 27 Dec 2019 14:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:in-reply-to:to; bh=wFeGvxCoeAGard2mj3W/m6wSBUqtlVrV1RuYlvnCQPw=; b=HewhuERTHMG3SW9kxFcmz1dH4fTKowCOHgqeBiOeZUfTjmkDU56AzDzvjDdzd/tmI1 ecvaYv2rZkQngeLSZ7KbG/mFVXHfriFtUifCiLXxohLGuvcf62qTwOIymWCRl6JfmJW4 e0GN4p2sbkobS2WSAzTX8U1vjvMbsOKAOTpv9vcLmeX4QgfGd6jHX3F8XkmeruuuTa+q 1eH1a+rg2vTrIeSrfYzGQFfrhLZvWah6BpigPXm5P71enISqEkRSsfFO1YeNd6KKWJ66 rmCfMSqrv5owHOeKGOzU4Br6Mz5V+/bgPMIXtxxqtLIMVuH4BN0bGAKZv1SYueyftWXS 8m5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:in-reply-to:to; bh=wFeGvxCoeAGard2mj3W/m6wSBUqtlVrV1RuYlvnCQPw=; b=JYPODa+Snl75xK/sydTBR0Ng1nXhO1gGS/2MxQZoyET6B8E5ORLWNYCdAxDdX4bFAu O6pQhZy0MNN0Spqqp/oVabUJ93aW7dm/CU9ulvoMD3Ktkk4JjhS+leyhMSNEuGXyzjtY TZpjlSflM9Ou00JGzhqjt3OrBsG3VjdyiAgfE2xH78HeiInUEJDIBesFENQu8jJbQnvX 1f4zt1Th5R28Un7TZXmT1mSY7cdoMqocMYGeT44LqjsUIukE8ddPbnDLYGodiDamxBql 6/hjTeA5kJ0FoOeTSO28Q+EaZKtCnsNcncncl/wpgXxW1uyi9JQ1symyQxoEEHzh9LqR ipGw== X-Gm-Message-State: APjAAAWZRTkRPNLRyrZ68R3TdNpkm5iJZPA/amjifyv+Fs76AgN9bHFV 3UrpEpaWvLL+UACA6U3PX/EnsgmPng== X-Google-Smtp-Source: APXvYqxWJ9SlrBCpAVYBhEb2k6rXXhjO7URwl2JKri46g+HT5qmdyTelo30TgUodef8sF3iZfG07qg== X-Received: by 2002:adf:f3d1:: with SMTP id g17mr53800314wrp.378.1577485634799; Fri, 27 Dec 2019 14:27:14 -0800 (PST) Received: from [192.168.1.107] (ip-37-188-164-151.eurotel.cz. [37.188.164.151]) by smtp.gmail.com with ESMTPSA id z11sm35973058wrt.82.2019.12.27.14.27.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Dec 2019 14:27:13 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-FAB27BA0-0A67-46DE-920E-ECBF2E76B197 Content-Transfer-Encoding: 7bit From: Filip Skokan Mime-Version: 1.0 (1.0) Date: Fri, 27 Dec 2019 23:27:11 +0100 Message-Id: References: <0D6C9677-D8B5-4005-95FE-4F783EB28961@lodderstedt.net> In-Reply-To: <0D6C9677-D8B5-4005-95FE-4F783EB28961@lodderstedt.net> To: oauth X-Mailer: iPhone Mail (17C54) Archived-At: Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 22:27:20 -0000 --Apple-Mail-FAB27BA0-0A67-46DE-920E-ECBF2E76B197 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Encrypted JARM responses are in a very similar position. Access Token value i= s not part of the URL and the response itself is protected. Such response is= usually only consumed by a server side application. Same as any form_post r= esponse.=20 We could go into further clarifying the client application topology to enabl= e these uses but i don=E2=80=99t think it=E2=80=99s worth it. Why make excus= es to keep implicit issued access tokens around in when code flow is the way= the WG has decided to go. (Here we go again...) Best, Filip > 27. 12. 2019 v 21:41, Torsten Lodderstedt : >=20 > =EF=BB=BF > As Brian said, we have discussed this several times and this text found co= nsensus. >=20 > Using post reduces the attack surface but does not allow to bind the acces= s token to the legitimate client. We are recommending sender constrained acc= ess tokens in the BCP. So recommending a flow that does not support sender c= onstrained access tokens is a contradiction. >=20 > What do other WG members think? >=20 >>> Am 27.12.2019 um 21:28 schrieb Mike Jones : >>>=20 >> =EF=BB=BF >> I agree with Brian. Please update the text to describe this already safe u= sage. >>=20 >> -- Mike >>=20 >> From: OAuth on behalf of Brian Campbell >> Sent: Friday, December 27, 2019 11:03:30 AM >> To: oauth >> Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response type= s + form_post response mode >> =20 >> We have a-sometimes used scenario where a client makes an authorization/a= uthentication request with a "token id_token" response type and "form_post" r= esponse mode (nonce is also sent and exact redirect URI matching is done at t= he AS). The access token is never exposed in any URLs and access token injec= tion is prevented by the at_hash claim in the id token.=20 >>=20 >> That seems to me like a legitimate and reasonable usage scenario. However= , it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the S= ecurity BCP-to-be, which has: >>=20 >> In order to avoid these issues, clients SHOULD NOT use the implicit >> grant (response type "token") or any other response type issuing >> access tokens in the authorization response, such as "token id_token" >> and "code token id_token", unless the issued access tokens are >> sender-constrained and access token injection in the authorization >> response is prevented. >>=20 >> I know this particular text has been discussed over and over again so I h= ate to revisit it. But based on the aforementioned scenario I think maybe it= still doesn't quite hit the mark. Access token injection is prevented. The t= oken leakage scenarios mentioned in that section are all avoided. And while I= know sender-constrained is recommended elsewhere in the draft, it's not rea= lly a realistic option for the majority of deployments.=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, d= istribution or disclosure by others is strictly prohibited.. If you have re= ceived this communication in error, please notify the sender immediately by e= -mail and delete the message and any file attachments from your computer. Th= ank you. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-FAB27BA0-0A67-46DE-920E-ECBF2E76B197 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Encrypted JARM responses are in a very simi= lar position. Access Token value is not part of the URL and the response its= elf is protected. Such response is usually only consumed by a server side ap= plication. Same as any form_post response. 

We could= go into further clarifying the client application topology to enable these u= ses but i don=E2=80=99t think it=E2=80=99s worth it. Why make excuses to kee= p implicit issued access tokens around in when code flow is the way the WG h= as decided to go. (Here we go again...)

Best,
=
Filip

27. 12. 2= 019 v 21:41, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.= ietf.org>:

=EF=BB=BF
As Brian said, we have discussed this several t= imes and this text found consensus.

Using post reduces the attack surface but does not allow to bind th= e access token to the legitimate client. We are recommending sender constrai= ned access tokens in the BCP. So recommending a flow that does not support s= ender constrained access tokens is a contradiction.
What do other WG members think?

Am 27.12.2019 um 21:28 schrieb Mike Jones &= lt;Michael.Jones=3D40microsoft.com@dmarc.ietf.org>:

<= /div>
=EF=BB=BF =
I agree with Brian. Please update the text to describe this already safe usa= ge.

-- Mike

From: OAuth <oauth-bounces= @ietf.org> on behalf of Brian Campbell <bcampbell=3D40pingidentity.com= @dmarc.ietf.org>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <oauth@ietf.org>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response t= ypes + form_post response mode
 
We have a-sometimes used scenario where a client makes an authorization= /authentication request with a "token id_token" response type and "form_post= " response mode (nonce is also sent and exact redirect URI matching is done a= t the AS). The access token is never exposed in any URLs and access token injection is prevented by the= at_hash claim in the id token.

That seems to me like a legitimate and reasonable usage scenario. Howev= er, it would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security BCP-to-be, which has:

   In order to avoid these issues, clients SHOULD NOT use the= implicit
   grant (response type "token") or any other response type issuin= g
   access tokens in the authorization response, such as "token id_= token"
   and "code token id_token", unless the issued access tokens are<= br>    sender-constrained and access token injection in the authorizat= ion
   response is prevented.

I know this particular text has been discussed over and over again so I= hate to revisit it. But based on the aforementioned scenario I think maybe i= t still doesn't quite hit the mark. Access token injection is prevented. The= token leakage scenarios mentioned in that section are all avoided. And while I know sender-constrained is rec= ommended elsewhere in the draft, it's not really a realistic option for the m= ajority of deployments.

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the= sole use of the intended recipient(s). Any review, use, distribution or dis= closure by others is strictly prohibited..  If you have received this c= ommunication in error, please notify the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
<= /div>= --Apple-Mail-FAB27BA0-0A67-46DE-920E-ECBF2E76B197--