From nobody Sat Jun 6 08:47:38 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B85C1B3337; Sat, 6 Jun 2015 08:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 R0mIBf9ZCnZr; Sat, 6 Jun 2015 08:47:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA361B333C; Sat, 6 Jun 2015 08:47:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150606154735.6795.9024.idtracker@ietfa.amsl.com> Date: Sat, 06 Jun 2015 08:47:35 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 15:47:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-12.txt Pages : 18 Date : 2015-06-06 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-spop-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 8 05:36:26 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4001A3BA3; Mon, 8 Jun 2015 05:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham 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 6o7VrPPxt8xM; Mon, 8 Jun 2015 05:36:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 732CE1A1EF2; Mon, 8 Jun 2015 05:36:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 05:36:17 -0700 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 12:36:19 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-introspection-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- All of the stuff below is fairly minor and isn't blocking... but I would like to discuss with you any items that you disagree with, please. -- Section 1 --    This specification defines an interoperable web API How is that different from, "This specification defines an API"?  I don't know why a web API differs from any other kind of API, nor what makes an API particularly interoperable. That said, this document appears not to be defining an API at all... it seems to be defining a protocol.  Why do you think it's an API? -- Section 2 --    The introspection endpoint MUST be protected by a transport-layer    security mechanism as described in Section 4. I know what it means for a communication path to be protected by TLS, but I don't know what it means for an endpoint to be. Can you explain that? -- Section 2.1 -- The server MUST support POST, and MAY support GET.  What's the value in that?  I don't see any way for a client (I mean HTTP client, not Oauth client, here) to know, so all clients will have to send POST to be sure it will work.  Are you really expecting to have clients that want to ask this, but that can't send POST? Given that you call out privacy concerns with GET, I don't see why it's there at all. -- Section 2.2 -- The definition of "scope" is odd, because I think you mean that it's a single JSON string, and that the content of the string is a space-separated list of scope values... it's not actually multiple JSON strings, right? -- Section 3.1 -- I'd REALLY like to see us stop trying to tell IANA how to handle review by designated experts.  This should be re-cast as instructions to the DE (to make sure that the mailing list is consulted), and IANA should be left to handle the expert review with their existing process, which works fine. While we're at it, it would be nice to have some further instruction to the DEs about what they should be looking at when deciding whether to approve a request.  There's some very minimal instruction under "name" in the template, but that's all.  Is there nothing more to say? -- References -- Because many of the items in the response are defined in RFC 7519, I think that RFC should be a normative reference. From nobody Mon Jun 8 06:55:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482DE1A7026; Mon, 8 Jun 2015 06:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 DCtgEUVejDhV; Mon, 8 Jun 2015 06:55:44 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::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 B4B101A8823; Mon, 8 Jun 2015 06:55:37 -0700 (PDT) Received: by wiga1 with SMTP id a1so87397905wig.0; Mon, 08 Jun 2015 06:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Fl4JlOXWiy+4K3+mgwobzyF8DN+wrWJ6xNkQ/hzgYs=; b=g85D+MEH+Cxs0/qc+YA35XiL05Kyt8iraZXfC6Jd1hkUwRwYoWo/QJM8aB/BhIuId3 R8ygy2+PXsiq9C62ZqU6LNr9e78lZ7pGW+wzR3I3StOWC3yRFcWxu8erHQYu4G/3GrUx +M+vOD1Jm9Ht720Dum5xiNfn75My/nFi2Hodolevqj09C0iTBo4HhBXV7HSWsmEmErSH fRqwUFmVEDU7eO1D0daeVVUnulVcyBtELvn9UntLSS6nwDicDpjSd0yJw80ACvOdzo0w i84R1kcUKzZHBbq3shHOg/cBLzevJmMOTq/5JDIfNT10X1rs6CACYvxzm0Ig43zcp9KV mfgw== MIME-Version: 1.0 X-Received: by 10.194.9.104 with SMTP id y8mr33155685wja.86.1433771736369; Mon, 08 Jun 2015 06:55:36 -0700 (PDT) Received: by 10.28.148.148 with HTTP; Mon, 8 Jun 2015 06:55:36 -0700 (PDT) In-Reply-To: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> References: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> Date: Mon, 8 Jun 2015 09:55:36 -0400 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b5d9889090dc3051801ffe9 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, "oauth@ietf.org" , draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , oauth-chairs@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 13:55:46 -0000 --047d7b5d9889090dc3051801ffe9 Content-Type: text/plain; charset=UTF-8 Hi Barry, Thanks very much for your detailed review. I have one comment inline. On Mon, Jun 8, 2015 at 8:36 AM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-introspection-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > All of the stuff below is fairly minor and isn't blocking... but I would > like to discuss with you any items that you disagree with, please. > > -- Section 1 -- > > This specification defines an interoperable web API > > How is that different from, "This specification defines an API"? I don't > know why a web API differs from any other kind of API, nor what makes an > API particularly interoperable. That said, this document appears not to > be defining an API at all... it seems to be defining a protocol. Why do > you think it's an API? > > -- Section 2 -- > > The introspection endpoint MUST be protected by a transport-layer > security mechanism as described in Section 4. > > I know what it means for a communication path to be protected by TLS, but > I don't know what it means for an endpoint to be. Can you explain that? > > -- Section 2.1 -- > The server MUST support POST, and MAY support GET. What's the value in > that? I don't see any way for a client (I mean HTTP client, not Oauth > client, here) to know, so all clients will have to send POST to be sure > it will work. Are you really expecting to have clients that want to ask > this, but that can't send POST? Given that you call out privacy concerns > with GET, I don't see why it's there at all. > > -- Section 2.2 -- > The definition of "scope" is odd, because I think you mean that it's a > single JSON string, and that the content of the string is a > space-separated list of scope values... it's not actually multiple JSON > strings, right? > > -- Section 3.1 -- > I'd REALLY like to see us stop trying to tell IANA how to handle review > by designated experts. This should be re-cast as instructions to the DE > (to make sure that the mailing list is consulted), and IANA should be > left to handle the expert review with their existing process, which works > fine. > OAuth and JOSE have been using mailing lists where several DEs are on the list and others can join. These lists are separate from the WG mailing list. DEs are names with IANA, but the spec review happens on that list, which is open. This practice pre-date me as an AD. I don't see what's wrong with it as it separates out the requests from the WG mailing list, but is still open and transparent. Changing it now would alter how this spec works and would make it different from the other OAuth specs, which could be confusing. > While we're at it, it would be nice to have some further instruction to > the DEs about what they should be looking at when deciding whether to > approve a request. There's some very minimal instruction under "name" in > the template, but that's all. Is there nothing more to say? > I agree with this advice. Thanks, Kathleen > > -- References -- > Because many of the items in the response are defined in RFC 7519, I > think that RFC should be a normative reference. > > > -- Best regards, Kathleen --047d7b5d9889090dc3051801ffe9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Barry,

Thanks very much for your det= ailed review.=C2=A0 I have one comment inline.

On Mon, Jun 8, 2015 at 8:36 AM, Barry Le= iba <barryleiba@computer.org> wrote:
Barry Leiba has entered the following ballot position for
draft-ietf-oauth-introspection-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-cr= iteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-intro= spection/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

All of the stuff below is fairly minor and isn't blocking... but I woul= d
like to discuss with you any items that you disagree with, please.

-- Section 1 --

=C2=A0 =C2=A0This specification defines an interoperable web API

How is that different from, "This specification defines an API"?= =C2=A0 I don't
know why a web API differs from any other kind of API, nor what makes an API particularly interoperable.=C2=A0 That said, this document appears not = to
be defining an API at all... it seems to be defining a protocol.=C2=A0 Why = do
you think it's an API?

-- Section 2 --

=C2=A0 =C2=A0The introspection endpoint MUST be protected by a transport-la= yer
=C2=A0 =C2=A0security mechanism as described in Section 4.

I know what it means for a communication path to be protected by TLS, but I don't know what it means for an endpoint to be.=C2=A0 Can you explain= that?

-- Section 2.1 --
The server MUST support POST, and MAY support GET.=C2=A0 What's the val= ue in
that?=C2=A0 I don't see any way for a client (I mean HTTP client, not O= auth
client, here) to know, so all clients will have to send POST to be sure
it will work.=C2=A0 Are you really expecting to have clients that want to a= sk
this, but that can't send POST?=C2=A0 Given that you call out privacy c= oncerns
with GET, I don't see why it's there at all.

-- Section 2.2 --
The definition of "scope" is odd, because I think you mean that i= t's a
single JSON string, and that the content of the string is a
space-separated list of scope values... it's not actually multiple JSON=
strings, right?

-- Section 3.1 --
I'd REALLY like to see us stop trying to tell IANA how to handle review=
by designated experts.=C2=A0 This should be re-cast as instructions to the = DE
(to make sure that the mailing list is consulted), and IANA should be
left to handle the expert review with their existing process, which works fine.

OAuth and JOSE have been using ma= iling lists where several DEs are on the list and others can join.=C2=A0 Th= ese lists are separate from the WG mailing list.=C2=A0 DEs are names with I= ANA, but the spec review happens on that list, which is open.=C2=A0 This pr= actice pre-date me as an AD.=C2=A0 I don't see what's wrong with it= as it separates out the requests from the WG mailing list, but is still op= en and transparent.=C2=A0 Changing it now would alter how this spec works a= nd would make it different from the other OAuth specs, which could be confu= sing.



While we're at it, it would be nice to have some further instruction to=
the DEs about what they should be looking at when deciding whether to
approve a request.=C2=A0 There's some very minimal instruction under &q= uot;name" in
the template, but that's all.=C2=A0 Is there nothing more to say?

I agree with this advice.

Thanks,
Kathleen=C2=A0

-- References --
Because many of the items in the response are defined in RFC 7519, I
think that RFC should be a normative reference.





--

Best regards,
Kath= leen
--047d7b5d9889090dc3051801ffe9-- From nobody Mon Jun 8 08:40:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ED51B2F75; Mon, 8 Jun 2015 08:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 GaPd0bTe1ODb; Mon, 8 Jun 2015 08:40:45 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 B0DEB1B2F44; Mon, 8 Jun 2015 08:40:19 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so64597404igb.1; Mon, 08 Jun 2015 08:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8AN1xD3f7GfYmx3BA99Niw6jBMYWHRM8H1E+hXiR8Qk=; b=sYdGcTMvkzHsJUly+Aw1EmU1NVFN8bgpEPthQ9b7iDCsO+iabQRD3oZOsN6IvJO1O4 rIVNGAWV5rRCLLKNEHkxyy7/mqeVCa4aHf4f+3jucVn650F/MTgpkxuFToOl5/6fUk1t nu0zTeAN5AvnPbu7k6wcXvBSOEFpVQNOk9DEJvKjVkdqIljdRNC6e64X4nHXByb3w2Qf DWcUoFX0F1kNMDMJNDakeDnK8MKps+ZS/h4wIL9foSpx47S4e8N+PRjlMrQF+DSKDBBE /CjmFi9sTs2GZaYM98qU9F9XQ2uXAPgFBnfLVn2jz+MMYRAgDdwOVSMVAqXRBp4Mp4Ce /B9A== MIME-Version: 1.0 X-Received: by 10.50.4.66 with SMTP id i2mr14375712igi.40.1433778019116; Mon, 08 Jun 2015 08:40:19 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.16.222 with HTTP; Mon, 8 Jun 2015 08:40:19 -0700 (PDT) In-Reply-To: References: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> Date: Mon, 8 Jun 2015 11:40:19 -0400 X-Google-Sender-Auth: SBeF-6-GRI8PbOT0JspvV1MHLWo Message-ID: From: Barry Leiba To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:40:50 -0000 >> -- Section 3.1 -- >> I'd REALLY like to see us stop trying to tell IANA how to handle review >> by designated experts. This should be re-cast as instructions to the DE >> (to make sure that the mailing list is consulted), and IANA should be >> left to handle the expert review with their existing process, which works >> fine. > > OAuth and JOSE have been using mailing lists where several DEs are on the > list and others can join. These lists are separate from the WG mailing > list. DEs are names with IANA, but the spec review happens on that list, > which is open. This practice pre-date me as an AD. I don't see what's > wrong with it as it separates out the requests from the WG mailing list, but > is still open and transparent. Changing it now would alter how this spec > works and would make it different from the other OAuth specs, which could be > confusing. I'm not objecting to the mailing list. I'm objecting to telling IANA how to integrate the mailing list into its procedure, which is different from what its procedure is. IANA initiates expert review when it receives a request, contacting the DE and tracking the process. This tells IANA to send people directly to the mailing list, and only to deal with requests from the DE. The fact that requests need to be discussed on the mailing list is something that the DE should be dealing with as part of her review, and that takes us out of the business of telling IANA how to initiate and track expert review, and making Oauth reviews different from those for other protocols. Barry From nobody Mon Jun 8 12:42:53 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3681C1B2F47; Mon, 8 Jun 2015 12:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 8sy3jR5Syw6j; Mon, 8 Jun 2015 12:42:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 703BC1ACD1D; Mon, 8 Jun 2015 12:42:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608194249.3968.61933.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 12:42:49 -0700 Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 19:42:51 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-spop-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- How does "plain" do anything at all to mitigate this attack?  Wouldn't anyone who could snag the grant also be able to snag the code verifier as well?  Why is "plain" even here? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General: I would think that this mechanism should never be a substitute for using TLS, and that this document should be explicit about that, and should say that the proper mitigation for situations where TLS can be used... is to use TLS.  Is there a reason we should NOT say that? Putting quotation marks around "code_verifier" and "code_challenge" in the formulas is confusing: it makes it look as if you're putting in those strings themselves, rather than the values of the variables.  It's probably unlikely that anyone would make that mistake, but I nevertheless suggest removing the quotation marks when you mean to refer to the values. -- Section 2 -- I don't understand the distinction between STRING and ASCII(STRING).  Can you please explain it? -- Section 4.3 -- If "plain" does stay, why on Earth is it the default?  Even if just for form's sake, shouldn't S256 be the default? -- Section 4.4 -- The word "code" is used for too many things, and "Authorization Grant" is already the right name for what we're talking about here.  I suggest that in both the section title and body you use that term, to make it clear what you mean by the "code". Similarly, in Section 4.5 please say "code_verifier" rather than "secret". -- Section 4.4.1 -- Please expand "PKCE", which is, at the moment, only expanded in the document title. -- Section 5 -- The SHOULD in the first paragraph is wrong.  You already have a MAY covering the general behavior.  You should just take out the "SHOULD", and just say that severs supporting backwards compatibility revert to the normal OAuth protocol. -- Section 6.2 -- I have the same comment here as in the other OAuth document: please shift the focus away from telling IANA how to handle tracking of the expert review, and make the mailing list something that the designated expert(s) keep track of. Also, please give more instructions to the DEs about what they should consider when they're evaluating a request (for example, should they approve all requests, or are there criteria they should apply?). For the first, here's a text change that I suggest we move toward for this sort of thing: OLD NEW Additional code_challenge_method types for use with the authorization endpoint are registered using the Specification Required policy [RFC5226], which includes review of the request by one or more Designated Experts. The DEs will ensure there is at least a two-week review of the request on the oauth-ext-review@ietf.org mailing list, and that any discussion on that list converges before they respond to the request. To allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that an acceptable specification will be published. Discussion on the oauth-ext-review@ietf.org mailing list should use an appropriate subject, such as "Request for PKCE code_challenge_method: example"). The Designated Expert(s) should consider the discussion on the mailing list, as well as <> when evaluating registration requests. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. END -- Section 7.2 -- Please rewrite the first paragraph. Please do not leave it for the RFC Editor, as they may inadvertently get it technically wrong when they try. From nobody Tue Jun 9 09:07:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3A91A8AB3; Tue, 9 Jun 2015 09:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FhYF0uMNirq6; Tue, 9 Jun 2015 09:07:51 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054AC1A8AAE; Tue, 9 Jun 2015 09:07:50 -0700 (PDT) X-AuditID: 12074425-f79076d000000db5-c3-55770f54cce5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D9.11.03509.45F07755; Tue, 9 Jun 2015 12:07:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t59G7lKd014867; Tue, 9 Jun 2015 12:07:47 -0400 Received: from [192.168.3.54] ([12.217.69.145]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t59G7e0I028655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jun 2015 12:07:42 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4AEFC267-260D-4F00-BB82-D1BC392A3136"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> Date: Tue, 9 Jun 2015 09:07:37 -0700 Message-Id: References: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFKsWRmVeSWpSXmKPExsUixCmqrRvCXx5q8H66rMWhxZdYLc5uus1u sWJ5ucWLxTuZLWb8mchscXvuSjaLk29fsTmwe7Ss6mX2WLLkJ1MAUxSXTUpqTmZZapG+XQJX xtyfU9kL7qtXXDx0m7WB8ZBCFyMnh4SAicSqM+vYIWwxiQv31rN1MXJxCAksZpJY9nMOE4Sz gVHifONyVghnNZNET8MysBZhgXSJ4w/fsoHYvAJ6Eo+ePmYHKWIWmMIo8fDEPSaIuVISTa+P MYLYbAKqEtPXtADFOTg4BRwlvs0IBwmzCKhIrPn5gwWi9xejxJMjO9khhlpJfJzbDNYrJOAg cek9SBEnh4iApsTzz1PA5kgIyEp83So3gVFwFpIzZiE7AyTBLKAtsWzha2YIW1Nif/dyFghb XmL72zlQcUuJxTNvQMVtJW71LYDqtZN4NG0R6wJGjlWMsim5Vbq5iZk5xanJusXJiXl5qUW6 Fnq5mSV6qSmlmxhB0cbuorqDccIhpUOMAhyMSjy8JxTKQoVYE8uKK3MPMUpyMCmJ8przlIcK 8SXlp1RmJBZnxBeV5qQWH2JUAdr1aMPqC4xSLHn5ealKIrx7nwC18qYkVlalFuXDlElzsCiJ 8276wRciJJCeWJKanZpakFoEk5Xh4FCS4M3lA1ogWJSanlqRlplTgpBm4uA8xCjBwQM0/Ccv UA1vcUFibnFmOkT+FKOilDjvNZCEAEgiozQPrheWJF8xigO9JcyrBLKCB5hg4bpfAQ1mAhq8 kBlscEkiQkqqgbGivi028mk5o2d5/BLvA/NXNy9hWN7xT7ss4pnebyWuOaoZBn77q5+KyLar 39Pirsy6X/fucK/fsWkaziLxijxLIgx1mneFHvnQqL1vU3LAjw13CyX5TORXPLuzfI79G8Hq eSGLXlnv6rFykopsa3u3417XzMBGobSKZrElBwJrZVIeKUZYKrEUZyQaajEXFScCACBXRIlt AwAA Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "" Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:07:54 -0000 --Apple-Mail=_4AEFC267-260D-4F00-BB82-D1BC392A3136 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Barry, thanks for the review. Responses inline. > On Jun 8, 2015, at 5:36 AM, Barry Leiba = wrote: >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-introspection-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > All of the stuff below is fairly minor and isn't blocking... but I = would > like to discuss with you any items that you disagree with, please. >=20 > -- Section 1 -- >=20 > This specification defines an interoperable web API >=20 > How is that different from, "This specification defines an API"? I = don't > know why a web API differs from any other kind of API, nor what makes = an > API particularly interoperable. That said, this document appears not = to > be defining an API at all... it seems to be defining a protocol. Why = do > you think it's an API? >=20 I=E2=80=99m fine with just calling it a protocol, I don=E2=80=99t want = people to garden-path on it. > -- Section 2 -- >=20 > The introspection endpoint MUST be protected by a transport-layer > security mechanism as described in Section 4. >=20 > I know what it means for a communication path to be protected by TLS, = but > I don't know what it means for an endpoint to be. Can you explain = that? The gist is simple: It must be served over HTTPS, not HTTP. >=20 > -- Section 2.1 -- > The server MUST support POST, and MAY support GET. What's the value = in > that? I don't see any way for a client (I mean HTTP client, not Oauth > client, here) to know, so all clients will have to send POST to be = sure > it will work. Are you really expecting to have clients that want to = ask > this, but that can't send POST? Given that you call out privacy = concerns > with GET, I don't see why it's there at all. >=20 GET is a deployment optimization that some servers will offer, and the = OAuth client will tell the HTTP client which verb to use. The OAuth = client might know through configuration (assuming a tighter coupling = than defined by the interoperable protocol) > -- Section 2.2 -- > The definition of "scope" is odd, because I think you mean that it's a > single JSON string, and that the content of the string is a > space-separated list of scope values... it's not actually multiple = JSON > strings, right? >=20 You are correct in your reading and that=E2=80=99s a better way to state = that, thank you. > -- Section 3.1 -- > I'd REALLY like to see us stop trying to tell IANA how to handle = review > by designated experts. This should be re-cast as instructions to the = DE > (to make sure that the mailing list is consulted), and IANA should be > left to handle the expert review with their existing process, which = works > fine. >=20 > While we're at it, it would be nice to have some further instruction = to > the DEs about what they should be looking at when deciding whether to > approve a request. There's some very minimal instruction under "name" = in > the template, but that's all. Is there nothing more to say? >=20 > -- References -- > Because many of the items in the response are defined in RFC 7519, I > think that RFC should be a normative reference. >=20 >=20 That=E2=80=99s a fair comment, I=E2=80=99ll change that. Thank you, =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4AEFC267-260D-4F00-BB82-D1BC392A3136 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVdw9JAAoJEDPAngkbd+w9MvUH+wZdrIFgrzdByIDp3v/THrmk WEBP8nCxjPoUJ26wwyhFWpFNvbVX2IN2wAFwIAobIP8A4q9dKSQ3FGpbDzyaJOQ7 QFNfQ7hDLivJ/I2fBEVln2wXNs6H91Nge3l4ttMiUGwBsBujyDPi1DjDiBUHyyKN m+V2a5O6oHir1IDl7ve2U5p3S1HonpwZ7S7Z4UxWZCdpwAA9+MU7M1PEOX4yjTl+ gsHhRoOz8pWnV4ywS0FmvSO5RgcHiCnb/cxfXFTamakvE3K0WfgIqcsREmkLkS/2 NUMc1GiSQBISCuo1AOlQFS7OhQaGAVM+va2Hi1b6+FJh9reFwua+h+nSfHBSVmA= =Fdbm -----END PGP SIGNATURE----- --Apple-Mail=_4AEFC267-260D-4F00-BB82-D1BC392A3136-- From nobody Tue Jun 9 09:57:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FCC1A9133; Tue, 9 Jun 2015 09:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 pOCLse0iStzZ; Tue, 9 Jun 2015 09:57:18 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 E291F1A0BE8; Tue, 9 Jun 2015 09:57:17 -0700 (PDT) Received: by igblz2 with SMTP id lz2so15997831igb.1; Tue, 09 Jun 2015 09:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PuRQv7MulisP2CX/HNo5/NhP9ipLgGWZlCnhXAX5UNo=; b=abK9ffxhPjKIWsKjhi4CWWHU6Axs/3m5gI0nyXIM2J4uShNpWtpZ1KzOdD2NTbYdxP g5EyNzIGU9gPMXdhrjwD2OfdnMwZVuKqvu6959ejW/W7unAlf8ZvcvPfZCiMIOcOTE0g sUy0B/0nKlFy6t7j9X7oprIm6RjeEX562CRlil5WSpXcr0FVfHnJJcpD0IXCHZYF9QEo 6Ii3SKtZaslLY2QzN6ZNCjH6tK/cH7G8Zbp+zW6J3q8nelQMZYVq3MCtw/hRNplmfPLg fXCaVEsrLM+2tidddya9cukDRF+A9AzIYOapGBdKX5bK/yOsKPo2GbSKmSIT5XPxvWB+ +kGA== MIME-Version: 1.0 X-Received: by 10.43.34.205 with SMTP id st13mr30509908icb.4.1433869037465; Tue, 09 Jun 2015 09:57:17 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.16.222 with HTTP; Tue, 9 Jun 2015 09:57:17 -0700 (PDT) In-Reply-To: References: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> Date: Tue, 9 Jun 2015 17:57:17 +0100 X-Google-Sender-Auth: D-xzMbp_FwqrTTTcSKbSHjqn8T8 Message-ID: From: Barry Leiba To: Justin Richer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "" Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:57:19 -0000 Hi, Justin. Thanks for the response and discussion. >> -- Section 2 -- >> >> The introspection endpoint MUST be protected by a transport-layer >> security mechanism as described in Section 4. >> >> I know what it means for a communication path to be protected by TLS, but >> I don't know what it means for an endpoint to be. Can you explain that? > > The gist is simple: It must be served over HTTPS, not HTTP. Right; that's protecting the communication path. So I suggest this (and it's a minor point; I'm OK with no further discussion, whether you agree with the change or not): NEW The introspection communication path MUST be protected by a transport-layer security mechanism as described in Section 4. END >> -- Section 2.1 -- >> The server MUST support POST, and MAY support GET. What's the value in >> that? I don't see any way for a client (I mean HTTP client, not Oauth >> client, here) to know, so all clients will have to send POST to be sure >> it will work. Are you really expecting to have clients that want to ask >> this, but that can't send POST? Given that you call out privacy concerns >> with GET, I don't see why it's there at all. > > GET is a deployment optimization that some servers will offer, and the > OAuth client will tell the HTTP client which verb to use. The OAuth client > might know through configuration (assuming a tighter coupling than > defined by the interoperable protocol) Two things: 1. Why is GET an optimization? It has privacy disadvantages, and I don't see any advantages. 2. This "tight coupling" thing is something that I think weakens the interoperability of the OAuth protocol in general, and I've never liked it. In this case, in particular, I don't see any advantage to it, and I don't understand why it's useful to have an option that only works if you have inside knowledge, for no benefit. Why is it ever good to have clients that only work with certain servers, when it's just as easy to make sure that all clients work with all servers? Barry From nobody Tue Jun 9 19:40:12 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497E91A00B7; Tue, 9 Jun 2015 19:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 kNepH5k4mR71; Tue, 9 Jun 2015 19:40:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D282A1A0097; Tue, 9 Jun 2015 19:40:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610024008.30330.79118.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 19:40:08 -0700 Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: [OAUTH-WG] Joel Jaeggli's No Objection on draft-ietf-oauth-spop-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 02:40:10 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-oauth-spop-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >From Melinda Shore's OPSdir review: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document is ready, with very minor issues. It does not appear to introduce new management/manageability considerations. This document describes a challenge-response mechanism to protect against an OAuth authorization code being intercepted by an attacker, when that authorization code is sent in the clear. The authorization code is used to acquire an access token and must be protected. This attack (an attacker using an intercepted authz code to acquire an access token) has been observed in the wild. We are astonished to learn that OAuth is being run over an unencrypted channel. However, given that it is, this is a reasonable defense mechanism. Questions: Why is S256 RECOMMENDED and not a MUST? Nits: ASCII(STRING) does not appear to be used in the protocol grammar? Melinda From nobody Wed Jun 10 00:04:35 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E1F1A886C; Wed, 10 Jun 2015 00:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.047 X-Spam-Level: *** X-Spam-Status: No, score=3.047 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 Zhma4Nj6ADku; Wed, 10 Jun 2015 00:04:27 -0700 (PDT) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511541A1EF4; Wed, 10 Jun 2015 00:04:20 -0700 (PDT) Received: from nriea04.index.or.jp (unknown [172.19.246.39]) by nrifs04.index.or.jp (Postfix) with SMTP id E01DC472EE4; Wed, 10 Jun 2015 16:04:19 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea04.index.or.jp (unknown) with ESMTP id t5A74Jq4031712; Wed, 10 Jun 2015 16:04:19 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t5A74JrI058473; Wed, 10 Jun 2015 16:04:19 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id t5A74JsE058472; Wed, 10 Jun 2015 16:04:19 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t5A74Jxg058469; Wed, 10 Jun 2015 16:04:19 +0900 Received: from NatCFRZ4 (unknown [172.31.163.114]) by nrivpnfs02.index.or.jp (Postfix) with ESMTP id B96B558162; Wed, 10 Jun 2015 16:04:07 +0900 (JST) Message-ID: <36D1546CCAE1477491A4FF9FBA8D2FF2@NatCFRZ4> From: "Nat Sakimura" To: "Barry Leiba" , "The IESG" References: <20150608194249.3968.61933.idtracker@ietfa.amsl.com> In-Reply-To: <20150608194249.3968.61933.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 16:04:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-MailAdviser: 20150401 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-oauth-spop.ad@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 07:04:30 -0000 Thanks Barry for the comment. My (personal) responses inline. John and Naveen, if you have anything to add, please chime in. > > -----Original Message-----=20 > From: Barry Leiba > Sent: Tuesday, June 09, 2015 4:42 AM > To: The IESG > Cc: draft-ietf-oauth-spop@ietf.org ; oauth-chairs@ietf.org ;=20 > draft-ietf-oauth-spop.shepherd@ietf.org ; oauth@ietf.org ;=20 > draft-ietf-oauth-spop.ad@ietf.org > Subject: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12:=20 > (with DISCUSS and COMMENT) > > Barry Leiba has entered the following ballot position for > draft-ietf-oauth-spop-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > How does "plain" do anything at all to mitigate this attack? Wouldn't > anyone who could snag the grant also be able to snag the code verifier = as > well? Why is "plain" even here? > You have to understand that this spec deals with a scenario that the=20 communication is conducted over two segments: (1) Unprotected: Within the machine through mechanisms like custom=20 scheme. (2) Protected: Over the network, which is protected by TLS. The =E2=80=9Csnagging=E2=80=9D happens over the segment (1). For example,= an attacker can=20 snag the grant over this segment. However, he cannot snag code verifier because it is sent over (2), which = is=20 TLS protected. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > General: > I would think that this mechanism should never be a substitute for usin= g > TLS, and that this document should be explicit about that, and should s= ay > that the proper mitigation for situations where TLS can be used... is t= o > use TLS. Is there a reason we should NOT say that? OAuth (RFC6749 and RFC6750) mandates the use of TLS over the network. PKCE inherits this property. We could mention it again here, but it is so= rt=20 of already done by inheritance. > > Putting quotation marks around "code_verifier" and "code_challenge" in > the formulas is confusing: it makes it look as if you're putting in tho= se > strings themselves, rather than the values of the variables. It's > probably unlikely that anyone would make that mistake, but I neverthele= ss > suggest removing the quotation marks when you mean to refer to the > values. That=E2=80=99s the peculiarity of the current XML2TXT converter. In XML, it is to signify strings themselves rather= than=20 the values of the variables. It renders nicely on HTML format etc., but TXT seem to have this confusin= g=20 property. Perhaps RFC Editor can deal with. > > -- Section 2 -- > I don't understand the distinction between STRING and ASCII(STRING). C= an > you please explain it? It is a notation used by JSON Web Signature, etc. It is making sure not to conflate the sequence of characters with sequenc= e=20 of octets of characters. > > -- Section 4.3 -- > If "plain" does stay, why on Earth is it the default? Even if just for > form's sake, shouldn't S256 be the default? It is partly historical. The draft started off there, then kept adding ot= her=20 mechanisms. There are many implementations of PKCE now but the largest=20 portion of it is using =E2=80=9Cplain=E2=80=9D. For the sake of interoper= ability with=20 them, it needs to stay as it is written. > > -- Section 4.4 -- > The word "code" is used for too many things, and "Authorization Grant" = is > already the right name for what we're talking about here. I suggest th= at > in both the section title and body you use that term, to make it clear > what you mean by the "code". RFC 6749 defines two types of Authorization Grant: Authorization Code and= =20 Implicit. In PKCE, we are specifically dealing with Authorization Code so= =20 replacing them with Authorization Grant loosens it up and is not desirabl= e.=20 I agree that we have been a bit lax in the use of the term =E2=80=9Ccode=E2= =80=9D as an=20 abbreviation of =E2=80=9CAuthorization Code=E2=80=9D. Also, looking at th= e TXT=20 representation of the spec, largely due to the formatting peculiarity, it= is=20 making them even more confusing than compared to other format. Therefore,= I=20 suggest the following: - Replace all occurrence of =E2=80=9Ccode=E2=80=9D as an abbreviation of = =E2=80=9CAuthorization=20 Code=E2=80=9D with =E2=80=9CAuthorization Code=E2=80=9D. - Capitalize the defined term =E2=80=9Ccode challenge=E2=80=9D and =E2=80= =9Ccode verifier=E2=80=9D so=20 that there will become =E2=80=9CCode Challenge=E2=80=9D and =E2=80=9CCode= Verifier=E2=80=9D throughout. > Similarly, in Section 4.5 please say "code_verifier" rather than "secre= t". Good catch. Accept. > > -- Section 4.4.1 -- > Please expand "PKCE", which is, at the moment, only expanded in the > document title. Suggest the following: Replace =E2=80=9Cthis extension=E2=80=9D of the last paragraph of 1. Intr= oduction by=20 =E2=80=9CProof Key for Code Exchange (PKCE) extension=E2=80=9D. Add =E2=80=9C3.1 Abbreviation=E2=80=9D subsection and collect the abbrevi= ations that are=20 used in this specification, namely: - PKCE =E2=80=93 Proof Key for (Authorization) Code Exchange - Authz -- Authorization - App =E2=80=93 Application - MITM =E2=80=93 Man In The Middle I guess we do not need to list IESG, IANA, and RFC in it=E2=80=A6 > > -- Section 5 -- > The SHOULD in the first paragraph is wrong. You already have a MAY > covering the general behavior. You should just take out the "SHOULD", > and just say that severs supporting backwards compatibility revert to t= he > normal OAuth protocol. Accept in principle, but at the same time, I feel that explicitly writing= =20 that the server is expected to fall back to RFC6749 and RFC6750 mode with= out=20 error probably is useful for developers. For this purpose, this =E2=80=9C= SHOULD=E2=80=9D=20 while redundant, could be useful. Perhaps, just replacing =E2=80=9CSHOULD= =E2=80=9D with=20 =E2=80=9Cshould=E2=80=9D suffice? > > -- Section 6.2 -- > I have the same comment here as in the other OAuth document: please shi= ft > the focus away from telling IANA how to handle tracking of the expert > review, and make the mailing list something that the designated expert(= s) > keep track of. Also, please give more instructions to the DEs about wh= at > they should consider when they're evaluating a request (for example, > should they approve all requests, or are there criteria they should > apply?). > > For the first, here's a text change that I suggest we move toward for > this sort of thing: > > OLD > > > NEW > Additional code_challenge_method types for use with the authorizatio= n > endpoint are registered using the Specification Required policy > [RFC5226], which includes review of the request by one or more > Designated Experts. The DEs will ensure there is at least a two-wee= k > review of the request on the oauth-ext-review@ietf.org mailing list, > and that any discussion on that list converges before they respond t= o > the request. To allow for the allocation of values prior to > publication, the Designated Expert(s) may approve registration once > they are satisfied that an acceptable specification will be > published. > > Discussion on the oauth-ext-review@ietf.org mailing list should use > an appropriate subject, such as "Request for PKCE > code_challenge_method: example"). > > The Designated Expert(s) should consider the discussion on the > mailing list, as well as <> when evaluating > registration requests. Denials should include an explanation > and, if applicable, suggestions as to how to make the request > successful. > END Thanks. The editors were just trying to be consistent with the way the=20 parent spec was dealing with this kind of things, but if the suggested wa= y=20 is preferred, we can certainly do it. > > -- Section 7.2 -- > Please rewrite the first paragraph. Please do not leave it for the RFC > Editor, as they may inadvertently get it technically wrong when they tr= y. > Would something like this work? OLD Clients MUST NOT try down grading the algorithm after trying S256 method.= If=20 the server is PKCE compliant, then S256 method works. If the server does = not=20 support PKCE, it does not generate error. Only the time that the server=20 returns that it does not support S256 is there is a MITM trying the=20 algorithm downgrade attack. NEW Clients MUST NOT down grade the algorithm after trying the S256 method.=20 There is no legitimate case that such a downgrade become necessary since=20 S256 method always works if the server supports PKCE and it does not=20 generate error if the server does not. Only the time that the server retu= rns=20 error that it does not support S256 is that there is a MITM attacker tryi= ng=20 the algorithm downgrade attack. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth=20 From nobody Wed Jun 10 06:22:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857E11B3078; Mon, 8 Jun 2015 09:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no 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 tPdKgoF5mrkG; Mon, 8 Jun 2015 09:40:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 485181A924A; Mon, 8 Jun 2015 09:40:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 09:40:44 -0700 Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 06:21:52 -0700 Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 16:40:45 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-oauth-introspection-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- = Section 2.1 = "The endpoint MAY allow other parameters to provide further context to the query. For instance, an authorization service may need to know the IP address of the client accessing the protected resource in order to determine the appropriateness of the token being presented." How does the protected resource know whether it needs to include such additional parameters or not? What is meant by the "appropriateness" of the token? In general if we're talking about a piece of data that could be sensitive like client IP address, it would be better for there to be specific guidelines to direct protected resources as to when this information needs to be sent. I note that Section 5 basically says such considerations are out of scope, but if this specific example is to be provided here then they seem in scope to me. = Section 5 = "One way to limit disclosure is to require authorization to call the introspection endpoint and to limit calls to only registered and trusted protected resource servers." I thought Section 2.1 made authorization to call the introspection endpoint mandatory. This makes it sound like it's optional. Which is it? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Section 1.1 = There is no reference to RFC2119 here, which may be okay but most documents include it if they use normative language (I think). = Section 2 = "The definition of an active token is up to the authorization server, but this is commonly a token that has been issued by this authorization server, is not expired, has not been revoked, and is within the purview of the protected resource making the introspection call." Is "within the purview" a term of art for OAuth 2.0? Is there a more specific way to describe what is meant here? Also, I note that in the description of the "active" member in Section 2.2, this criterion is not listed. It seems like these should be aligned. = Section 2.2 = "Note that in order to avoid disclosing too much of the authorization server's state to a third party, the authorization server SHOULD NOT include any additional information about an inactive token, including why the token is inactive." Seems like this should be a MUST NOT unless there's some reason for providing anything other than active set to false. Same comment applies in Section 4. = Section 2.3 = It seems like there is another error condition and I'm wondering if its handling needs to be specified. Per my question in Section 2.1, if it's possible that the request is properly formed but is missing some additional information that the authorization server needs to evaluate it, should there be an error condition specified for that case? From nobody Wed Jun 10 06:22:06 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B071A1B14; Tue, 9 Jun 2015 14:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 N5ZWsB4ORNNR; Tue, 9 Jun 2015 14:31:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFC81A1AFF; Tue, 9 Jun 2015 14:31:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609213118.20446.71588.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 14:31:18 -0700 Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 06:21:52 -0700 Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-spop-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 21:31:20 -0000 Ben Campbell has entered the following ballot position for draft-ietf-oauth-spop-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share Barry's and Alexey's concerns about both allowing "plain" and defaulting to it. I have some other comments, which may overlap with the comments from others: Substantive: -- section 1, pre-condition 3: "All OAuth 2.0 native app client-instances use the same client_id. Secrets provisioned in client binary applications cannot be considered confidential." Is that part of the pre-condition per-se, or a general statement? If the former, wouldn't a potential mitigation for this attack be to ensure the precondition doesn't occur? -- section 1, paragraph after precondition list: "not applicable since they rely on a per-client instance secret or aper client instance redirect URI." I infer that these are not realistic? If so, it might be useful to say why. For instance, would one way to mitigate this attack be to make sure you have per-client secrets and redirect URIs? -- 4.4.1, last sentence: Does this advice change if people register new challenge methods? That is, what if the client supports "plain", and "foo" but not S256, where foo is more secure than plain. Can it still use "plain"? -- 6.2: Does the ability to register new challenge methods introduce bid-down attacks? (Assuming that any such method is more secure than "plain", and that the server might not support it.) Also, I share Barry's concern that the registration procedures require quite a bit of special treatment from IANA. -- 7.4: This seems to need a normative reference to 6819. -- 7.5: How does the guidance in section 10.8 of 6479 apply to the code_verifier? Also, I think the last sentence requires this draft (or some other) to update 6749. Editorial: -- 4.4, 2nd to last paragraph: "The server MUST NOT include the "code_challenge" value in client requests in a form that other entities can extract." should "client requests" be "responses to clients"? (I assume the server does not send client requests--or do I have the terminology wrong?) -- 4.4.1, first paragraph: Please expand PKCE on first mention. (It might help to declare PKCE in the introduction.) From nobody Wed Jun 10 06:22:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66A61A9030; Tue, 9 Jun 2015 17:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1RDCvbl-nZMP; Tue, 9 Jun 2015 17:24:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5B21A902B; Tue, 9 Jun 2015 17:24:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610002416.13636.71337.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 17:24:16 -0700 Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 06:21:52 -0700 Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 00:24:22 -0000 Ben Campbell has entered the following ballot position for draft-ietf-oauth-introspection-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I concur with Alissa's discuss. Additional comments: -- There is no reference to RFC 2119, but there seems to be lots of capitalized 2119 keywords. If those are intended to have the 2119 meaning, please add the usual reference. (I assume that these are intended as 2119 keywords for the remainder of the review.) -- 2.1, first paragraph: If the server MAY support GET, how does a client know to use it? Would you expect them to try and fail? -- 3 Is there a reason not to use a more standard IANA procedure? (I.e. let people request registrations to IANA, and have them forward the requests to the DE?) --3.1, under "Name" The MUST seems unnecessary, as that's the whole point of a registry. -- 4: The security considerations have a lot of restated 2119 keywords. If you want to reinforce those here, it would be better to do so with descriptive language, rather than having multiple occurrences of the same normative language. Redundant normative language is error prone, especially for future updates. -- 4, bullet list: It seems odd to have 2119 keywords in a "For instance" section. --4, 6th paragraph from end The reference to [TLS.BCP] should probably be normative. -- 4, last two paragraphs: "An authorization server offering token introspection MUST be able to understand the token values being presented to it during this call." and "the authorization server MUST be able to decrypt and validate the token in order to access this information." These seem more like statements of fact than normative language. From nobody Wed Jun 10 06:54:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9514D1B2A59; Wed, 10 Jun 2015 06:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 rAJ5ig2bTJqq; Wed, 10 Jun 2015 06:54:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6680E1B2A35; Wed, 10 Jun 2015 06:54:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610135456.14302.51415.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 06:54:56 -0700 Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: [OAUTH-WG] Brian Haberman's No Objection on draft-ietf-oauth-spop-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 13:54:57 -0000 Brian Haberman has entered the following ballot position for draft-ietf-oauth-spop-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Barry's DISCUSS about "plain". Using "plain" makes no sense to me. From nobody Wed Jun 10 07:12:48 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856AA1B2ACB; Wed, 10 Jun 2015 07:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 kIHiBXX6QA0J; Wed, 10 Jun 2015 07:12:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9FF1B2AC8; Wed, 10 Jun 2015 07:12:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610141244.19755.30964.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 07:12:44 -0700 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Brian Haberman's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 14:12:46 -0000 Brian Haberman has entered the following ballot position for draft-ietf-oauth-introspection-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * In Section 2.1... is the authorization service and the introspection endpoint the same device? From nobody Wed Jun 10 16:02:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B121A87A1; Wed, 10 Jun 2015 16:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 BiVkyRXJzwXi; Wed, 10 Jun 2015 16:02:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5C01A874D; Wed, 10 Jun 2015 16:02:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610230201.17676.49585.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 16:02:01 -0700 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Benoit Claise's No Record on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 23:02:02 -0000 Benoit Claise has entered the following ballot position for draft-ietf-oauth-introspection-09: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Interested in the answer to Alissa's DISCUSS point 1 From nobody Thu Jun 11 02:14:50 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336CB1B2DE7; Thu, 11 Jun 2015 02:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.047 X-Spam-Level: *** X-Spam-Status: No, score=3.047 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no 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 Ev9P-sBfCTkp; Thu, 11 Jun 2015 02:14:46 -0700 (PDT) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CA81AC429; Thu, 11 Jun 2015 02:14:45 -0700 (PDT) Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs04.index.or.jp (Postfix) with SMTP id 4BBA0472EDF; Thu, 11 Jun 2015 18:14:43 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp (unknown) with ESMTP id t5B9Egdf016627; Thu, 11 Jun 2015 18:14:42 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t5B9EgiW063740; Thu, 11 Jun 2015 18:14:42 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id t5B9Egfe063739; Thu, 11 Jun 2015 18:14:42 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id t5B9Ego0063734; Thu, 11 Jun 2015 18:14:42 +0900 Message-ID: <5BE6FB696E5B4ADEB0CE45F116A4881A@NatCFRZ4> From: "Nat Sakimura" To: "Ben Campbell" , "The IESG" References: <20150609213118.20446.71588.idtracker@ietfa.amsl.com> In-Reply-To: <20150609213118.20446.71588.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 18:14:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-MailAdviser: 20150401 Archived-At: Cc: draft-ietf-oauth-spop.ad@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-spop-12: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 09:14:48 -0000 Thanks Ben for the comments. My responses inline. > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Wednesday, June 10, 2015 6:31 AM > To: The IESG > Cc: draft-ietf-oauth-spop@ietf.org; oauth-chairs@ietf.org; > draft-ietf-oauth-spop.shepherd@ietf.org; oauth@ietf.org; > draft-ietf-oauth-spop.ad@ietf.org > Subject: [OAUTH-WG] Ben Campbell's No Objection on > draft-ietf-oauth-spop-12: > (with COMMENT) > > Ben Campbell has entered the following ballot position for > draft-ietf-oauth-spop-12: No Objection > > When responding, please keep the subject line intact and reply to all > email > addresses included in the To and CC lines. (Feel free to cut this > introductory > paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I share Barry's and Alexey's concerns about both allowing "plain" and > defaulting > to it. I have some other comments, which may overlap with the comments Please see my and John's response to Barry. > others: > > Substantive: > > -- section 1, pre-condition 3: "All OAuth 2.0 native app client-instances > use > the same client_id. Secrets provisioned in client binary applications > cannot > be considered confidential." > > Is that part of the pre-condition per-se, or a general statement? If the > former, > wouldn't a potential mitigation for this attack be to ensure the > precondition > doesn't occur? It is describing the state we are in, and the state is a prerequisite for the attck to succeed. > > -- section 1, paragraph after precondition list: "not applicable since > they rely > on a per-client instance secret or aper client instance > redirect URI." > > I infer that these are not realistic? If so, it might be useful to say > why. For > instance, would one way to mitigate this attack be to make sure you have > per-client > secrets and redirect URIs? > Per-client secrets to tens of millions of clients adds serverside headache by requiring persistent serverside client state. Also, the client development overhead become much larger now that the client has to be capable of doing dynamic client registration. These combined, tendency of the developer is to ignore the risk. PKCE provides a way to mitigate the risk without persistent serverside state nor development overhead of dynamic client registration. > -- 4.4.1, last sentence: > > Does this advice change if people register new challenge methods? That > is, what > if the client supports "plain", and "foo" but not S256, where foo is more > secure > than plain. Can it still use "plain"? Client needs to a priori know that the server supports "foo". Otherwise, it will be a target for algorithm downgrade attack. If the Client knows that the server supports "foo", then the client must not accept "plain". > > -- 6.2: > > Does the ability to register new challenge methods introduce bid-down > attacks? > (Assuming that any such method is more secure than "plain", and that the > server > might not support it.) Please see the above. > > Also, I share Barry's concern that the registration procedures require > quite > a bit of special treatment from IANA. Please see the response to Barry. > > -- 7.4: > > This seems to need a normative reference to 6819. We can move it from Informative Reference to Normative if referring it in SHOULD qualifies it for. > > -- 7.5: How does the guidance in section 10.8 of 6749 apply to the > code_verifier? code_verifier will be transmitted in the clear between the app and the system browser in the main use case. > Also, I think the last sentence requires this draft (or some other) to > update > 6749. Probably yes, but that is a separate issue, I suppose. > > Editorial: > > -- 4.4, 2nd to last paragraph: "The server MUST NOT include the > "code_challenge" > value in client requests in a form that other entities can extract." > > should "client requests" be "responses to clients"? (I assume the server > does > not send client requests--or do I have the terminology wrong?) I think that my bad English. The intent was: The server MUST NOT include (the "code_challenge" value in the client request) in the code in a form that other entities can extract. I could restate it as: When the server embeds the received Code Challange in the Authorization Code, it MUST NOT be done in a form that other entities can extract it. > > -- 4.4.1, first paragraph: > Please expand PKCE on first mention. (It might help to declare PKCE in the > introduction.) Please see my response to Barry. I have proposed even a fuller alternative. Cheers, Nat Sakimura Nomura Research Institute. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (n-sakimura@nri.co.jp) Nomura Research Institute PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system. From nobody Thu Jun 11 03:36:03 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76411B2F26; Thu, 11 Jun 2015 03:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 xcH619_avkRh; Thu, 11 Jun 2015 03:36:00 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 4D0561B2F23; Thu, 11 Jun 2015 03:36:00 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so3519897igb.0; Thu, 11 Jun 2015 03:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=d1xR5FDxJ146HK7a9zqDIvKCp9zvnxmfmKnlt88ZiIY=; b=L/OL5qzUHreLMPR9WmWx8dsaY7MTm45kh5S9NiLoYxVywpqD+aXgTtL1glsIYwQeRO xdUewbvpS3s957X1pqzGa6d2V3oHPaH29cyh6qpBkV4IGJsr2hMKpnhpzKHXrQD082BA O9uMUyugt+VRBvouD+5GPjfl4MjLEW64McHEr7eISTBRNq53zRgUmgLrNpcMY2V7K50K gvwVJw9lXUb6t6cGzQemFILiPq+f5pyLBNUnVRV7+2D0NpyFXuRRqp/7gsi6ah21wXgd AhNvzZ0cGdwW8KYCB8VLcKp3kHVaYrMES4JFtzl5tjdSPn0X16/7PEWNNRdkbWQSqJdD uSsA== MIME-Version: 1.0 X-Received: by 10.107.25.199 with SMTP id 190mr10543589ioz.11.1434018959818; Thu, 11 Jun 2015 03:35:59 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.16.222 with HTTP; Thu, 11 Jun 2015 03:35:59 -0700 (PDT) In-Reply-To: <36D1546CCAE1477491A4FF9FBA8D2FF2@NatCFRZ4> References: <20150608194249.3968.61933.idtracker@ietfa.amsl.com> <36D1546CCAE1477491A4FF9FBA8D2FF2@NatCFRZ4> Date: Thu, 11 Jun 2015 11:35:59 +0100 X-Google-Sender-Auth: tn7FqwOsD3ntNVhai5w_WHzNrBc Message-ID: From: Barry Leiba To: Nat Sakimura Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth WG , draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth-chairs@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 10:36:03 -0000 Hi, Nat, and thanks for the reply. >> How does "plain" do anything at all to mitigate this attack? Wouldn't >> anyone who could snag the grant also be able to snag the code verifier a= s >> well? Why is "plain" even here? > > You have to understand that this spec deals with a scenario that the > communication is conducted over two segments: > (1) Unprotected: Within the machine through mechanisms like custom > scheme. > (2) Protected: Over the network, which is protected by TLS. > > The =E2=80=9Csnagging=E2=80=9D happens over the segment (1). For example,= an attacker can > snag the grant over this segment. > > However, he cannot snag code verifier because it is sent over (2), which = is > TLS protected. Well, the code verifier isn't sent at all, as I understand the protocol. It's the transformed version, the challenge, that's sent. Am I right? Now, you appear to be telling me that the challenge (and method) that are sent in Section 4.3 and the Authorization Response that is sent in Section 4.4 are sent in different ways (though you don't say that in the document), and that the transmission in 4.4 is open to interception, but the transmission in 4.3 is not. Is that an accurate summary? If it is correct that the transmission that's described in 4.3 can *never* be intercepted, then I'm a bit less worried about "plain". But given the simplicity of implementing S256: 1. If there's *any* possibility of interception in some scenarios, I still strongly oppose having "plain" at all, because if it's there, it's bound to be used when it shouldn't have been. 2. I don't buy the argument that it's OK to build a weaker protocol because implementors think that weak is good enough. I think we need to use our best protocol design principles and make sure what we publish as "standard" is what we think reflects the best protocol design. On to the less strenuous stuff... >> General: >> I would think that this mechanism should never be a substitute for using >> TLS, and that this document should be explicit about that, and should sa= y >> that the proper mitigation for situations where TLS can be used... is to >> use TLS. Is there a reason we should NOT say that? > > OAuth (RFC6749 and RFC6750) mandates the use of TLS over the network. > PKCE inherits this property. We could mention it again here, but it is so= rt > of already done by inheritance. That's true. I'll leave this to your judgment, and no need for further discussion. The reason I mentioned it was to make sure that implementors don't think that this mechanism can be a substitute for TLS. But if you think the OAuth specs are already solid enough on the TLS thing, I'm OK with that. >> Putting quotation marks around "code_verifier" and "code_challenge" in >> the formulas is confusing: it makes it look as if you're putting in thos= e >> strings themselves, rather than the values of the variables. It's >> probably unlikely that anyone would make that mistake, but I nevertheles= s >> suggest removing the quotation marks when you mean to refer to the >> values. > > That=E2=80=99s the peculiarity of the current XML2TXT converter. > In XML, it is to signify strings themselves rather= than > the values of the variables. > It renders nicely on HTML format etc., but TXT seem to have this confusin= g > property. > Perhaps RFC Editor can deal with. I don't understand that. When you say, for example: "code_verifier" =3D=3D "code_challenge" and BASE64URL-ENCODE(SHA256(ASCII("code_verifier" ))) =3D=3D "code_challenge" ...you are not referring to the strings, but to the values, so why are you marking them up at all? They should just be this way: code_verifier =3D=3D code_challenge and BASE64URL-ENCODE(SHA256(code_verifier)) =3D=3D code_challenge (see below about the "ASCII()" thing), with no markup causing quotation mar= ks. Or maybe I misunderstand what you're saying. And, no, I don't think we can leave it to the RFC Editor, unless we're quite explicit (with a note in the document) about telling them exactly what we want them to do. >> -- Section 2 -- >> I don't understand the distinction between STRING and ASCII(STRING). Ca= n >> you please explain it? > > It is a notation used by JSON Web Signature, etc. > It is making sure not to conflate the sequence of characters with sequenc= e > of octets of characters. You already define "STRING" as a sequence of ASCII characters (and you have "OCTETS" for arbitrary non-character octets). ASCII is already a character encoding. So there's no need to say that you have to take characters that are represented in ASCII, and represent them in ASCII. It's redundant, and it adds clutter. Of course, it's also not wrong, so this is not a DISCUSS, and you can do as you think best. I just suggest removing the "ASCII()" throughout, as it's totally unnecessary, and, as I say, it adds clutter. I'll note that your definition of "ASCII(STRING)" is quite convoluted, and the reason it's convoluted is that you have to twist yourself around a pole to make definition that says anything other than "ASCII(STRING) is just STRING". >> -- Section 4.3 -- >> If "plain" does stay, why on Earth is it the default? Even if just for >> form's sake, shouldn't S256 be the default? > > It is partly historical. The draft started off there, then kept adding ot= her > mechanisms. There are many implementations of PKCE now but the largest > portion of it is using =E2=80=9Cplain=E2=80=9D. For the sake of interoper= ability with them, > it needs to stay as it is written. In other words, if you change the default then existing implementations will have to change to match. I get that, but, again, we shouldn't be making our protocols suboptimal for that reason. I'd rather see us eliminate "plain" altogether, so I won't argue this further on this point. >> -- Section 4.4 -- >> The word "code" is used for too many things, and "Authorization Grant" i= s >> already the right name for what we're talking about here. I suggest tha= t >> in both the section title and body you use that term, to make it clear >> what you mean by the "code". > > RFC 6749 defines two types of Authorization Grant: Authorization Code and > Implicit. In PKCE, we are specifically dealing with Authorization Code so > replacing them with Authorization Grant loosens it up and is not desirabl= e. > I agree that we have been a bit lax in the use of the term =E2=80=9Ccode= =E2=80=9D as an > abbreviation of =E2=80=9CAuthorization Code=E2=80=9D. Also, looking at th= e TXT > representation of the spec, largely due to the formatting peculiarity, it= is > making them even more confusing than compared to other format. Therefore,= I > suggest the following: > > - Replace all occurrence of =E2=80=9Ccode=E2=80=9D as an abbreviation of = =E2=80=9CAuthorization > Code=E2=80=9D with =E2=80=9CAuthorization Code=E2=80=9D. Perfect; thanks. > - Capitalize the defined term =E2=80=9Ccode challenge=E2=80=9D and =E2=80= =9Ccode verifier=E2=80=9D so that > there will become =E2=80=9CCode Challenge=E2=80=9D and =E2=80=9CCode Veri= fier=E2=80=9D throughout. I like that too. >> -- Section 4.4.1 -- >> Please expand "PKCE", which is, at the moment, only expanded in the >> document title. > > Suggest the following: > Replace =E2=80=9Cthis extension=E2=80=9D of the last paragraph of 1. Intr= oduction by =E2=80=9CProof > Key for Code Exchange (PKCE) extension=E2=80=9D. > Add =E2=80=9C3.1 Abbreviation=E2=80=9D subsection and collect the abbrevi= ations that are > used in this specification, namely: > - PKCE =E2=80=93 Proof Key for (Authorization) Code Exchange > - Authz -- Authorization > - App =E2=80=93 Application > - MITM =E2=80=93 Man In The Middle That works well; thanks. > I guess we do not need to list IESG, IANA, and RFC in it=E2=80=A6 That's correct. The RFC Editor maintain a list of common abbreviations, noting those that don't need expansion. See http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt (You can get this from the main RFC Editor page by clicking on "RFC Style Guide", and then "Abbreviations List".) >> -- Section 5 -- >> The SHOULD in the first paragraph is wrong. You already have a MAY >> covering the general behavior. You should just take out the "SHOULD", >> and just say that severs supporting backwards compatibility revert to th= e >> normal OAuth protocol. > > Accept in principle, but at the same time, I feel that explicitly writing > that the server is expected to fall back to RFC6749 and RFC6750 mode with= out > error probably is useful for developers. For this purpose, this =E2=80=9C= SHOULD=E2=80=9D > while redundant, could be useful. Perhaps, just replacing =E2=80=9CSHOULD= =E2=80=9D with > =E2=80=9Cshould=E2=80=9D suffice? Again, not a DISCUSS, so use judgment. I think even "should" is totally unnecessary -- you're just saying how the protocol works. If you want compatibility, this is what you do. Not what you "should" do, but what you do in order to maintain compatibility. But no further discussion needed here. >> -- Section 6.2 -- >> I have the same comment here as in the other OAuth document: please shif= t >> the focus away from telling IANA how to handle tracking of the expert >> review, and make the mailing list something that the designated expert(s= ) >> keep track of. Also, please give more instructions to the DEs about wha= t >> they should consider when they're evaluating a request (for example, >> should they approve all requests, or are there criteria they should >> apply?). >> >> For the first, here's a text change that I suggest we move toward for >> this sort of thing: >> >> OLD >> >> >> NEW >> Additional code_challenge_method types for use with the authorization >> endpoint are registered using the Specification Required policy >> [RFC5226], which includes review of the request by one or more >> Designated Experts. The DEs will ensure there is at least a two-week >> review of the request on the oauth-ext-review@ietf.org mailing list, >> and that any discussion on that list converges before they respond to >> the request. To allow for the allocation of values prior to >> publication, the Designated Expert(s) may approve registration once >> they are satisfied that an acceptable specification will be >> published. >> >> Discussion on the oauth-ext-review@ietf.org mailing list should use >> an appropriate subject, such as "Request for PKCE >> code_challenge_method: example"). >> >> The Designated Expert(s) should consider the discussion on the >> mailing list, as well as <> when evaluating >> registration requests. Denials should include an explanation >> and, if applicable, suggestions as to how to make the request >> successful. >> END > > Thanks. The editors were just trying to be consistent with the way the > parent spec was dealing with this kind of things, but if the suggested wa= y > is preferred, we can certainly do it. Thanks! >> -- Section 7.2 -- >> Please rewrite the first paragraph. Please do not leave it for the RFC >> Editor, as they may inadvertently get it technically wrong when they try= . >> > Would something like this work? > > OLD > Clients MUST NOT try down grading the algorithm after trying S256 method.= If > the server is PKCE compliant, then S256 method works. If the server does = not > support PKCE, it does not generate error. Only the time that the server > returns that it does not support S256 is there is a MITM trying the > algorithm downgrade attack. > NEW > Clients MUST NOT down grade the algorithm after trying the S256 method. > There is no legitimate case that such a downgrade become necessary since > S256 method always works if the server supports PKCE and it does not > generate error if the server does not. Only the time that the server retu= rns > error that it does not support S256 is that there is a MITM attacker tryi= ng > the algorithm downgrade attack. Better, but still a little awkward. Let me take a stab and offer something= : NEWER Clients MUST NOT downgrade to "plain" after trying the S256 method. Because servers are required to support S256, an error when S256 is presented can only mean that the server does not support PKCE at all. Otherwise, such an error could be indicative of a MITM attacker trying a downgrade attack. END (And, of course, this isn't needed at all if we get rid of "plain".) Barry From nobody Thu Jun 11 05:45:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98CD1ACEB6 for ; Thu, 11 Jun 2015 05:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 CAEM-fDrWmMt for ; Thu, 11 Jun 2015 05:45:05 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (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 A87ED1A0022 for ; Thu, 11 Jun 2015 05:45:05 -0700 (PDT) Received: by pabqy3 with SMTP id qy3so3561183pab.3 for ; Thu, 11 Jun 2015 05:45:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=a5MBDFInAkjYTfEFETXmKhrBf3KI3UZg6JExexDEUWU=; b=BL9i8vjZDvEDi5J/MfdY/HOqtLfgYE0vBeelH+/9QKX1EMc5ty8DqxoPBNUM53vrW6 EfNNpmtI0V6Ek1vf23mCNl1W4KRrnwVPfifb50SDFxAE5THL4pkD3/ZCXWTWiyF5niVe gw+5HR+XkgrxHjmZ4WjpJiwKcOdt0vci5+CWSBlEGE4YmcR/6uh9wJqrVnA5FUgM8VY9 SD296SkXQ+kbHTPB/Gw8vehqA08hiYFonoWmKPWydMAUD4AjtfvkqDSXv0UcQYTjXJcN FPzfENhYCJtmVIqf52RR6tK9NzVh4zC79svdXg5Evm6R7xzntKuUvG4hbOBIaSh3FJHw BBZw== X-Gm-Message-State: ALoCoQnjBx3FCRWj0nA7Uv14OHXd3o54MSXaLZwt3l1rSYGYqRRpicUSjjwYMXgBkZN5hQzNjwXu X-Received: by 10.70.35.230 with SMTP id l6mr14819332pdj.26.1434026705209; Thu, 11 Jun 2015 05:45:05 -0700 (PDT) Received: from [192.168.4.139] (ip-64-134-236-21.public.wayport.net. [64.134.236.21]) by mx.google.com with ESMTPSA id a10sm727748pbu.15.2015.06.11.05.45.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jun 2015 05:45:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: Date: Thu, 11 Jun 2015 05:45:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <34824FDE-F0F8-4AD8-8824-3417B40C50C1@ve7jtb.com> References: <20150608194249.3968.61933.idtracker@ietfa.amsl.com> <36D1546CCAE1477491A4FF9FBA8D2FF2@NatCFRZ4> To: Barry Leiba X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth WG , draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 12:45:10 -0000 Hi Barry, The main attack and the origin of the spec is caused by a native app on = the device overloading the intent URI/custom scheme=20 that the legitimate OAuth client has registered as it=E2=80=99s = redirect_uri. The request path travels from the legitimate app to the system browser = by a secure API call, and can=E2=80=99t be intercepted unless the = attacker can replace the system browser. The browser then sends the request to the Authorization endpoint over = TLS per OAuth. That again would require a TLS man in the middle to = compromise and is no more a concern than any other use of TLS. The AS formulates it=E2=80=99s response and sends it back to the browser = over TLS as a 302. That again is fine and not a special concern. The attack comes when the browser uses the location header to call back = that native app on the device. Because of the nature of intent URI multiple apps can register the same = scheme, so are eligible to receive the response. On Android if there is more than one receiver registered the user is = prompted for what app they want invoked.=20 There is always a chance that the user will select the wrong app and the = attacker gets the Authorization Code. On iOS the selection behaviour depends on the version , in some versions = it just random, others select the most recently run app. =20 iOS 8 is random so an attacker has about a 50% chance of success in = intercepting the Authorization Code. The attack opportunity is only present in the response path, because the = way that the OS expose the API call to invoke the system browser is = diffrent from the way the system browser invokes the callback to a = native app. Given this we came up with the plain transform that requires no crypto = that no developer has an excuse for not using all the time. The code_challenge isn=E2=80=99t vulnerable to interception because it = is sent with a different API in the device. =20 The response containing the code has something like a 50% chance of = interception in the response, but doesn=E2=80=99t contain the = code_challenge. This attack being against a OS API method and not on the wire is why we = missed it in the OAuth spec. The plain transform is effective against this attack as the = communication of the code_challenge from the client to the AS is over a = secure API and TLS. The second attack is the one we don=E2=80=99t know about yet. It may be = a buffer leak in the OS or a weakness in the deployment that allows the = system browser to use SSL with a weak=20 alg that could be sniffed. I just don=E2=80=99t know, but as most = people realize that I am an exceptionally paranoid person=20 (Your gov is really watching me, I saw the DHS powerpoint. It is quite = funny, nice to have friends.) I insisted in including the S256 transform for all the other attacks, as = it is not much more complicated and if you can protect against sniffing = of the request then a reasonable person would do it. The specs I am = working on that use PKCE have S256 as a MUST. =20 So I talked the WG and deployers into putting S256 into the core PKCE = spec rather than having it as an extension as it was originally so that = it could be MTI for servers to implement. If we remove plain completely from the spec now, i may become the Google = equivalent of disappeared, as them agreeing to put S256 in has lead to = this. Keeping plain but changing code_challenge_method if not present to the = default of S256 will break existing deployments with PKCE standard = clients, or all the current clients without deploying new authorization = endpoints. =20 That would not be good for adoption. A compromise that might work for people would be making = code_challenge_method required, and removing the default language. That way we can say that the server MUST support S256, and that the = client SHOULD use S256. plain is for backwards compatibility, and for constrained environments = that are unable to do SHA256. If an attacker can modify the request, all they need to do is remove the = code_challenge to get around this unless the client has used client = registration to lock down a required=20 code_challenge_method, so we are not introducing a downgrade attack by = having plain that is not available to an attacker by removing PKCE = entirely from the request. Unfortunately this week is CIS for me and I am having a hard time = keeping up with email. Let me know what you think. =20 I agree that we want to direct developers to S256 as the preference, but = that only works if we get AS to deploy it, and developers to use it. John B. > On Jun 11, 2015, at 3:35 AM, Barry Leiba = wrote: >=20 > Hi, Nat, and thanks for the reply. >=20 >>> How does "plain" do anything at all to mitigate this attack? = Wouldn't >>> anyone who could snag the grant also be able to snag the code = verifier as >>> well? Why is "plain" even here? >>=20 >> You have to understand that this spec deals with a scenario that the >> communication is conducted over two segments: >> (1) Unprotected: Within the machine through mechanisms like custom >> scheme. >> (2) Protected: Over the network, which is protected by TLS. >>=20 >> The =E2=80=9Csnagging=E2=80=9D happens over the segment (1). For = example, an attacker can >> snag the grant over this segment. >>=20 >> However, he cannot snag code verifier because it is sent over (2), = which is >> TLS protected. >=20 > Well, the code verifier isn't sent at all, as I understand the > protocol. It's the transformed version, the challenge, that's sent. > Am I right? >=20 > Now, you appear to be telling me that the challenge (and method) that > are sent in Section 4.3 and the Authorization Response that is sent in > Section 4.4 are sent in different ways (though you don't say that in > the document), and that the transmission in 4.4 is open to > interception, but the transmission in 4.3 is not. Is that an accurate > summary? >=20 > If it is correct that the transmission that's described in 4.3 can > *never* be intercepted, then I'm a bit less worried about "plain". >=20 > But given the simplicity of implementing S256: >=20 > 1. If there's *any* possibility of interception in some scenarios, I > still strongly oppose having "plain" at all, because if it's there, > it's bound to be used when it shouldn't have been. >=20 > 2. I don't buy the argument that it's OK to build a weaker protocol > because implementors think that weak is good enough. I think we need > to use our best protocol design principles and make sure what we > publish as "standard" is what we think reflects the best protocol > design. >=20 > On to the less strenuous stuff... >=20 >>> General: >>> I would think that this mechanism should never be a substitute for = using >>> TLS, and that this document should be explicit about that, and = should say >>> that the proper mitigation for situations where TLS can be used... = is to >>> use TLS. Is there a reason we should NOT say that? >>=20 >> OAuth (RFC6749 and RFC6750) mandates the use of TLS over the network. >> PKCE inherits this property. We could mention it again here, but it = is sort >> of already done by inheritance. >=20 > That's true. I'll leave this to your judgment, and no need for > further discussion. The reason I mentioned it was to make sure that > implementors don't think that this mechanism can be a substitute for > TLS. But if you think the OAuth specs are already solid enough on the > TLS thing, I'm OK with that. >=20 >>> Putting quotation marks around "code_verifier" and "code_challenge" = in >>> the formulas is confusing: it makes it look as if you're putting in = those >>> strings themselves, rather than the values of the variables. It's >>> probably unlikely that anyone would make that mistake, but I = nevertheless >>> suggest removing the quotation marks when you mean to refer to the >>> values. >>=20 >> That=E2=80=99s the peculiarity of the current XML2TXT converter. >> In XML, it is to signify strings themselves = rather than >> the values of the variables. >> It renders nicely on HTML format etc., but TXT seem to have this = confusing >> property. >> Perhaps RFC Editor can deal with. >=20 > I don't understand that. When you say, for example: >=20 > "code_verifier" =3D=3D "code_challenge" >=20 > and >=20 > BASE64URL-ENCODE(SHA256(ASCII("code_verifier" ))) > =3D=3D "code_challenge" >=20 > ...you are not referring to the strings, but to the values, so why are > you marking them up at all? They should just be this way: >=20 > code_verifier =3D=3D code_challenge >=20 > and >=20 > BASE64URL-ENCODE(SHA256(code_verifier)) > =3D=3D code_challenge >=20 > (see below about the "ASCII()" thing), with no markup causing = quotation marks. >=20 > Or maybe I misunderstand what you're saying. And, no, I don't think > we can leave it to the RFC Editor, unless we're quite explicit (with a > note in the document) about telling them exactly what we want them to > do. >=20 >>> -- Section 2 -- >>> I don't understand the distinction between STRING and ASCII(STRING). = Can >>> you please explain it? >>=20 >> It is a notation used by JSON Web Signature, etc. >> It is making sure not to conflate the sequence of characters with = sequence >> of octets of characters. >=20 > You already define "STRING" as a sequence of ASCII characters (and you > have "OCTETS" for arbitrary non-character octets). ASCII is already a > character encoding. So there's no need to say that you have to take > characters that are represented in ASCII, and represent them in ASCII. > It's redundant, and it adds clutter. >=20 > Of course, it's also not wrong, so this is not a DISCUSS, and you can > do as you think best. I just suggest removing the "ASCII()" > throughout, as it's totally unnecessary, and, as I say, it adds > clutter. I'll note that your definition of "ASCII(STRING)" is quite > convoluted, and the reason it's convoluted is that you have to twist > yourself around a pole to make definition that says anything other > than "ASCII(STRING) is just STRING". >=20 >>> -- Section 4.3 -- >>> If "plain" does stay, why on Earth is it the default? Even if just = for >>> form's sake, shouldn't S256 be the default? >>=20 >> It is partly historical. The draft started off there, then kept = adding other >> mechanisms. There are many implementations of PKCE now but the = largest >> portion of it is using =E2=80=9Cplain=E2=80=9D. For the sake of = interoperability with them, >> it needs to stay as it is written. >=20 > In other words, if you change the default then existing > implementations will have to change to match. I get that, but, again, > we shouldn't be making our protocols suboptimal for that reason. I'd > rather see us eliminate "plain" altogether, so I won't argue this > further on this point. >=20 >>> -- Section 4.4 -- >>> The word "code" is used for too many things, and "Authorization = Grant" is >>> already the right name for what we're talking about here. I suggest = that >>> in both the section title and body you use that term, to make it = clear >>> what you mean by the "code". >>=20 >> RFC 6749 defines two types of Authorization Grant: Authorization Code = and >> Implicit. In PKCE, we are specifically dealing with Authorization = Code so >> replacing them with Authorization Grant loosens it up and is not = desirable. >> I agree that we have been a bit lax in the use of the term =E2=80=9Ccod= e=E2=80=9D as an >> abbreviation of =E2=80=9CAuthorization Code=E2=80=9D. Also, looking = at the TXT >> representation of the spec, largely due to the formatting = peculiarity, it is >> making them even more confusing than compared to other format. = Therefore, I >> suggest the following: >>=20 >> - Replace all occurrence of =E2=80=9Ccode=E2=80=9D as an abbreviation = of =E2=80=9CAuthorization >> Code=E2=80=9D with =E2=80=9CAuthorization Code=E2=80=9D. >=20 > Perfect; thanks. >=20 >> - Capitalize the defined term =E2=80=9Ccode challenge=E2=80=9D and = =E2=80=9Ccode verifier=E2=80=9D so that >> there will become =E2=80=9CCode Challenge=E2=80=9D and =E2=80=9CCode = Verifier=E2=80=9D throughout. >=20 > I like that too. >=20 >>> -- Section 4.4.1 -- >>> Please expand "PKCE", which is, at the moment, only expanded in the >>> document title. >>=20 >> Suggest the following: >> Replace =E2=80=9Cthis extension=E2=80=9D of the last paragraph of 1. = Introduction by =E2=80=9CProof >> Key for Code Exchange (PKCE) extension=E2=80=9D. >> Add =E2=80=9C3.1 Abbreviation=E2=80=9D subsection and collect the = abbreviations that are >> used in this specification, namely: >> - PKCE =E2=80=93 Proof Key for (Authorization) Code Exchange >> - Authz -- Authorization >> - App =E2=80=93 Application >> - MITM =E2=80=93 Man In The Middle >=20 > That works well; thanks. >=20 >> I guess we do not need to list IESG, IANA, and RFC in it=E2=80=A6 >=20 > That's correct. The RFC Editor maintain a list of common > abbreviations, noting those that don't need expansion. See > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > (You can get this from the main RFC Editor page by clicking on "RFC > Style Guide", and then "Abbreviations List".) >=20 >>> -- Section 5 -- >>> The SHOULD in the first paragraph is wrong. You already have a MAY >>> covering the general behavior. You should just take out the = "SHOULD", >>> and just say that severs supporting backwards compatibility revert = to the >>> normal OAuth protocol. >>=20 >> Accept in principle, but at the same time, I feel that explicitly = writing >> that the server is expected to fall back to RFC6749 and RFC6750 mode = without >> error probably is useful for developers. For this purpose, this = =E2=80=9CSHOULD=E2=80=9D >> while redundant, could be useful. Perhaps, just replacing = =E2=80=9CSHOULD=E2=80=9D with >> =E2=80=9Cshould=E2=80=9D suffice? >=20 > Again, not a DISCUSS, so use judgment. I think even "should" is > totally unnecessary -- you're just saying how the protocol works. If > you want compatibility, this is what you do. Not what you "should" > do, but what you do in order to maintain compatibility. But no > further discussion needed here. >=20 >>> -- Section 6.2 -- >>> I have the same comment here as in the other OAuth document: please = shift >>> the focus away from telling IANA how to handle tracking of the = expert >>> review, and make the mailing list something that the designated = expert(s) >>> keep track of. Also, please give more instructions to the DEs about = what >>> they should consider when they're evaluating a request (for example, >>> should they approve all requests, or are there criteria they should >>> apply?). >>>=20 >>> For the first, here's a text change that I suggest we move toward = for >>> this sort of thing: >>>=20 >>> OLD >>> >>>=20 >>> NEW >>> Additional code_challenge_method types for use with the = authorization >>> endpoint are registered using the Specification Required policy >>> [RFC5226], which includes review of the request by one or more >>> Designated Experts. The DEs will ensure there is at least a = two-week >>> review of the request on the oauth-ext-review@ietf.org mailing = list, >>> and that any discussion on that list converges before they respond = to >>> the request. To allow for the allocation of values prior to >>> publication, the Designated Expert(s) may approve registration = once >>> they are satisfied that an acceptable specification will be >>> published. >>>=20 >>> Discussion on the oauth-ext-review@ietf.org mailing list should = use >>> an appropriate subject, such as "Request for PKCE >>> code_challenge_method: example"). >>>=20 >>> The Designated Expert(s) should consider the discussion on the >>> mailing list, as well as <> when evaluating >>> registration requests. Denials should include an explanation >>> and, if applicable, suggestions as to how to make the request >>> successful. >>> END >>=20 >> Thanks. The editors were just trying to be consistent with the way = the >> parent spec was dealing with this kind of things, but if the = suggested way >> is preferred, we can certainly do it. >=20 > Thanks! >=20 >>> -- Section 7.2 -- >>> Please rewrite the first paragraph. Please do not leave it for the = RFC >>> Editor, as they may inadvertently get it technically wrong when they = try From nobody Thu Jun 11 05:55:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EDC1ACEC9; Thu, 11 Jun 2015 05:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 a-XN02F8Qu6O; Thu, 11 Jun 2015 05:54:57 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 C8C501ACEC8; Thu, 11 Jun 2015 05:54:56 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so54124360igb.1; Thu, 11 Jun 2015 05:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=8kGKRIw8BBCCZzIaErTNhPr+Z8BVkIqxcUlzXfGFWdc=; b=YDRcZmaZ2PSsPkYliFe6lfapHbXa93fdUVmE72PucSj4ou/YBeDY4QtBK9kwcSwBq8 3lnMmmvzxPsIsctxV2zPsMWYP19tjnzDLMHJFsNFSmND79PuoaybGJZCi4t8L6EGANeh eKTMWi+bD3IKZKbFfd7TpZ54Fi/xw7DPdOrqfeaJ3CO/hUwY8IQR39hRc5JOOlN6mZuD kDzjCI0qEVVU8kj22MGO10TrGJ/cjY7EF1V1XyUv3CFi+5jTOpPbPNWfB5HXdl+6Bhes eB89c/G+ODNfNG3U0fX4ZK3PqHwZq42T94ea/5fiWC8RVvZi27rNAUpkLJB2/fU2RI2P lG0g== MIME-Version: 1.0 X-Received: by 10.107.134.35 with SMTP id i35mr2687412iod.75.1434027296232; Thu, 11 Jun 2015 05:54:56 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.16.222 with HTTP; Thu, 11 Jun 2015 05:54:56 -0700 (PDT) In-Reply-To: <34824FDE-F0F8-4AD8-8824-3417B40C50C1@ve7jtb.com> References: <20150608194249.3968.61933.idtracker@ietfa.amsl.com> <36D1546CCAE1477491A4FF9FBA8D2FF2@NatCFRZ4> <34824FDE-F0F8-4AD8-8824-3417B40C50C1@ve7jtb.com> Date: Thu, 11 Jun 2015 13:54:56 +0100 X-Google-Sender-Auth: _bVFKH-KJdEWmdG-c6P1kvwtaXs Message-ID: From: Barry Leiba To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth WG , draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 12:55:00 -0000 John, thanks *very* much for this detailed background -- it's really helpful, and particularly helpful to get it before the telechat discussion. Given what you say, I still prefer the "no plain" path, because the inability to steal the challenge depends upon current OS implementations. That said, I'm much more open to accepting the current situation with the understanding that S256 is the path forward, and that plain is there to support existing use cases and deployment. It would be really good if some of this detail could be put into the Introduction so that readers can understand (1) why we're where we are and (2) why we should stop using plain for new situations, and stick with S256. So let's see where the discussion goes on the telechat. Barry On Thu, Jun 11, 2015 at 1:45 PM, John Bradley wrote: > Hi Barry, > > > The main attack and the origin of the spec is caused by a native app on t= he device overloading the intent URI/custom scheme > that the legitimate OAuth client has registered as it=E2=80=99s redirect_= uri. > > The request path travels from the legitimate app to the system browser by= a secure API call, and can=E2=80=99t be intercepted unless the attacker ca= n replace the system browser. > The browser then sends the request to the Authorization endpoint over TLS= per OAuth. That again would require a TLS man in the middle to compromise= and is no more a concern than any other use of TLS. > > The AS formulates it=E2=80=99s response and sends it back to the browser = over TLS as a 302. That again is fine and not a special concern. > The attack comes when the browser uses the location header to call back t= hat native app on the device. > > Because of the nature of intent URI multiple apps can register the same s= cheme, so are eligible to receive the response. > On Android if there is more than one receiver registered the user is prom= pted for what app they want invoked. > There is always a chance that the user will select the wrong app and the = attacker gets the Authorization Code. > > On iOS the selection behaviour depends on the version , in some versions = it just random, others select the most recently run app. > iOS 8 is random so an attacker has about a 50% chance of success in inter= cepting the Authorization Code. > > The attack opportunity is only present in the response path, because the = way that the OS expose the API call to invoke the system browser is diffren= t from the way the system browser invokes the callback to a native app. > > Given this we came up with the plain transform that requires no crypto th= at no developer has an excuse for not using all the time. > > The code_challenge isn=E2=80=99t vulnerable to interception because it is= sent with a different API in the device. > The response containing the code has something like a 50% chance of inter= ception in the response, but doesn=E2=80=99t contain the code_challenge. > > This attack being against a OS API method and not on the wire is why we m= issed it in the OAuth spec. > > The plain transform is effective against this attack as the communication= of the code_challenge from the client to the AS is over a secure API and T= LS. > > The second attack is the one we don=E2=80=99t know about yet. It may be = a buffer leak in the OS or a weakness in the deployment that allows the sys= tem browser to use SSL with a weak > alg that could be sniffed. I just don=E2=80=99t know, but as most peopl= e realize that I am an exceptionally paranoid person > (Your gov is really watching me, I saw the DHS powerpoint. It is quite f= unny, nice to have friends.) > > I insisted in including the S256 transform for all the other attacks, as = it is not much more complicated and if you can protect against sniffing of = the request then a reasonable person would do it. The specs I am working o= n that use PKCE have S256 as a MUST. > > So I talked the WG and deployers into putting S256 into the core PKCE spe= c rather than having it as an extension as it was originally so that it cou= ld be MTI for servers to implement. > > If we remove plain completely from the spec now, i may become the Google = equivalent of disappeared, as them agreeing to put S256 in has lead to this= . > > Keeping plain but changing code_challenge_method if not present to the de= fault of S256 will break existing deployments with PKCE standard clients, o= r all the current clients without deploying new authorization endpoints. > That would not be good for adoption. > > A compromise that might work for people would be making code_challenge_me= thod required, and removing the default language. > > That way we can say that the server MUST support S256, and that the clien= t SHOULD use S256. > > plain is for backwards compatibility, and for constrained environments th= at are unable to do SHA256. > > If an attacker can modify the request, all they need to do is remove the = code_challenge to get around this unless the client has used client registr= ation to lock down a required > code_challenge_method, so we are not introducing a downgrade attack by ha= ving plain that is not available to an attacker by removing PKCE entirely f= rom the request. > > Unfortunately this week is CIS for me and I am having a hard time keeping= up with email. > > Let me know what you think. > > I agree that we want to direct developers to S256 as the preference, but = that only works if we get AS to deploy it, and developers to use it. > > John B. > > > > >> On Jun 11, 2015, at 3:35 AM, Barry Leiba wrote= : >> >> Hi, Nat, and thanks for the reply. >> >>>> How does "plain" do anything at all to mitigate this attack? Wouldn't >>>> anyone who could snag the grant also be able to snag the code verifier= as >>>> well? Why is "plain" even here? >>> >>> You have to understand that this spec deals with a scenario that the >>> communication is conducted over two segments: >>> (1) Unprotected: Within the machine through mechanisms like custom >>> scheme. >>> (2) Protected: Over the network, which is protected by TLS. >>> >>> The =E2=80=9Csnagging=E2=80=9D happens over the segment (1). For exampl= e, an attacker can >>> snag the grant over this segment. >>> >>> However, he cannot snag code verifier because it is sent over (2), whic= h is >>> TLS protected. >> >> Well, the code verifier isn't sent at all, as I understand the >> protocol. It's the transformed version, the challenge, that's sent. >> Am I right? >> >> Now, you appear to be telling me that the challenge (and method) that >> are sent in Section 4.3 and the Authorization Response that is sent in >> Section 4.4 are sent in different ways (though you don't say that in >> the document), and that the transmission in 4.4 is open to >> interception, but the transmission in 4.3 is not. Is that an accurate >> summary? >> >> If it is correct that the transmission that's described in 4.3 can >> *never* be intercepted, then I'm a bit less worried about "plain". >> >> But given the simplicity of implementing S256: >> >> 1. If there's *any* possibility of interception in some scenarios, I >> still strongly oppose having "plain" at all, because if it's there, >> it's bound to be used when it shouldn't have been. >> >> 2. I don't buy the argument that it's OK to build a weaker protocol >> because implementors think that weak is good enough. I think we need >> to use our best protocol design principles and make sure what we >> publish as "standard" is what we think reflects the best protocol >> design. >> >> On to the less strenuous stuff... >> >>>> General: >>>> I would think that this mechanism should never be a substitute for usi= ng >>>> TLS, and that this document should be explicit about that, and should = say >>>> that the proper mitigation for situations where TLS can be used... is = to >>>> use TLS. Is there a reason we should NOT say that? >>> >>> OAuth (RFC6749 and RFC6750) mandates the use of TLS over the network. >>> PKCE inherits this property. We could mention it again here, but it is = sort >>> of already done by inheritance. >> >> That's true. I'll leave this to your judgment, and no need for >> further discussion. The reason I mentioned it was to make sure that >> implementors don't think that this mechanism can be a substitute for >> TLS. But if you think the OAuth specs are already solid enough on the >> TLS thing, I'm OK with that. >> >>>> Putting quotation marks around "code_verifier" and "code_challenge" in >>>> the formulas is confusing: it makes it look as if you're putting in th= ose >>>> strings themselves, rather than the values of the variables. It's >>>> probably unlikely that anyone would make that mistake, but I neverthel= ess >>>> suggest removing the quotation marks when you mean to refer to the >>>> values. >>> >>> That=E2=80=99s the peculiarity of the current XML2TXT converter. >>> In XML, it is to signify strings themselves rath= er than >>> the values of the variables. >>> It renders nicely on HTML format etc., but TXT seem to have this confus= ing >>> property. >>> Perhaps RFC Editor can deal with. >> >> I don't understand that. When you say, for example: >> >> "code_verifier" =3D=3D "code_challenge" >> >> and >> >> BASE64URL-ENCODE(SHA256(ASCII("code_verifier" ))) >> =3D=3D "code_challenge" >> >> ...you are not referring to the strings, but to the values, so why are >> you marking them up at all? They should just be this way: >> >> code_verifier =3D=3D code_challenge >> >> and >> >> BASE64URL-ENCODE(SHA256(code_verifier)) >> =3D=3D code_challenge >> >> (see below about the "ASCII()" thing), with no markup causing quotation = marks. >> >> Or maybe I misunderstand what you're saying. And, no, I don't think >> we can leave it to the RFC Editor, unless we're quite explicit (with a >> note in the document) about telling them exactly what we want them to >> do. >> >>>> -- Section 2 -- >>>> I don't understand the distinction between STRING and ASCII(STRING). = Can >>>> you please explain it? >>> >>> It is a notation used by JSON Web Signature, etc. >>> It is making sure not to conflate the sequence of characters with seque= nce >>> of octets of characters. >> >> You already define "STRING" as a sequence of ASCII characters (and you >> have "OCTETS" for arbitrary non-character octets). ASCII is already a >> character encoding. So there's no need to say that you have to take >> characters that are represented in ASCII, and represent them in ASCII. >> It's redundant, and it adds clutter. >> >> Of course, it's also not wrong, so this is not a DISCUSS, and you can >> do as you think best. I just suggest removing the "ASCII()" >> throughout, as it's totally unnecessary, and, as I say, it adds >> clutter. I'll note that your definition of "ASCII(STRING)" is quite >> convoluted, and the reason it's convoluted is that you have to twist >> yourself around a pole to make definition that says anything other >> than "ASCII(STRING) is just STRING". >> >>>> -- Section 4.3 -- >>>> If "plain" does stay, why on Earth is it the default? Even if just fo= r >>>> form's sake, shouldn't S256 be the default? >>> >>> It is partly historical. The draft started off there, then kept adding = other >>> mechanisms. There are many implementations of PKCE now but the largest >>> portion of it is using =E2=80=9Cplain=E2=80=9D. For the sake of interop= erability with them, >>> it needs to stay as it is written. >> >> In other words, if you change the default then existing >> implementations will have to change to match. I get that, but, again, >> we shouldn't be making our protocols suboptimal for that reason. I'd >> rather see us eliminate "plain" altogether, so I won't argue this >> further on this point. >> >>>> -- Section 4.4 -- >>>> The word "code" is used for too many things, and "Authorization Grant"= is >>>> already the right name for what we're talking about here. I suggest t= hat >>>> in both the section title and body you use that term, to make it clear >>>> what you mean by the "code". >>> >>> RFC 6749 defines two types of Authorization Grant: Authorization Code a= nd >>> Implicit. In PKCE, we are specifically dealing with Authorization Code = so >>> replacing them with Authorization Grant loosens it up and is not desira= ble. >>> I agree that we have been a bit lax in the use of the term =E2=80=9Ccod= e=E2=80=9D as an >>> abbreviation of =E2=80=9CAuthorization Code=E2=80=9D. Also, looking at = the TXT >>> representation of the spec, largely due to the formatting peculiarity, = it is >>> making them even more confusing than compared to other format. Therefor= e, I >>> suggest the following: >>> >>> - Replace all occurrence of =E2=80=9Ccode=E2=80=9D as an abbreviation o= f =E2=80=9CAuthorization >>> Code=E2=80=9D with =E2=80=9CAuthorization Code=E2=80=9D. >> >> Perfect; thanks. >> >>> - Capitalize the defined term =E2=80=9Ccode challenge=E2=80=9D and =E2= =80=9Ccode verifier=E2=80=9D so that >>> there will become =E2=80=9CCode Challenge=E2=80=9D and =E2=80=9CCode Ve= rifier=E2=80=9D throughout. >> >> I like that too. >> >>>> -- Section 4.4.1 -- >>>> Please expand "PKCE", which is, at the moment, only expanded in the >>>> document title. >>> >>> Suggest the following: >>> Replace =E2=80=9Cthis extension=E2=80=9D of the last paragraph of 1. In= troduction by =E2=80=9CProof >>> Key for Code Exchange (PKCE) extension=E2=80=9D. >>> Add =E2=80=9C3.1 Abbreviation=E2=80=9D subsection and collect the abbre= viations that are >>> used in this specification, namely: >>> - PKCE =E2=80=93 Proof Key for (Authorization) Code Exchange >>> - Authz -- Authorization >>> - App =E2=80=93 Application >>> - MITM =E2=80=93 Man In The Middle >> >> That works well; thanks. >> >>> I guess we do not need to list IESG, IANA, and RFC in it=E2=80=A6 >> >> That's correct. The RFC Editor maintain a list of common >> abbreviations, noting those that don't need expansion. See >> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt >> (You can get this from the main RFC Editor page by clicking on "RFC >> Style Guide", and then "Abbreviations List".) >> >>>> -- Section 5 -- >>>> The SHOULD in the first paragraph is wrong. You already have a MAY >>>> covering the general behavior. You should just take out the "SHOULD", >>>> and just say that severs supporting backwards compatibility revert to = the >>>> normal OAuth protocol. >>> >>> Accept in principle, but at the same time, I feel that explicitly writi= ng >>> that the server is expected to fall back to RFC6749 and RFC6750 mode wi= thout >>> error probably is useful for developers. For this purpose, this =E2=80= =9CSHOULD=E2=80=9D >>> while redundant, could be useful. Perhaps, just replacing =E2=80=9CSHOU= LD=E2=80=9D with >>> =E2=80=9Cshould=E2=80=9D suffice? >> >> Again, not a DISCUSS, so use judgment. I think even "should" is >> totally unnecessary -- you're just saying how the protocol works. If >> you want compatibility, this is what you do. Not what you "should" >> do, but what you do in order to maintain compatibility. But no >> further discussion needed here. >> >>>> -- Section 6.2 -- >>>> I have the same comment here as in the other OAuth document: please sh= ift >>>> the focus away from telling IANA how to handle tracking of the expert >>>> review, and make the mailing list something that the designated expert= (s) >>>> keep track of. Also, please give more instructions to the DEs about w= hat >>>> they should consider when they're evaluating a request (for example, >>>> should they approve all requests, or are there criteria they should >>>> apply?). >>>> >>>> For the first, here's a text change that I suggest we move toward for >>>> this sort of thing: >>>> >>>> OLD >>>> >>>> >>>> NEW >>>> Additional code_challenge_method types for use with the authorizatio= n >>>> endpoint are registered using the Specification Required policy >>>> [RFC5226], which includes review of the request by one or more >>>> Designated Experts. The DEs will ensure there is at least a two-wee= k >>>> review of the request on the oauth-ext-review@ietf.org mailing list, >>>> and that any discussion on that list converges before they respond t= o >>>> the request. To allow for the allocation of values prior to >>>> publication, the Designated Expert(s) may approve registration once >>>> they are satisfied that an acceptable specification will be >>>> published. >>>> >>>> Discussion on the oauth-ext-review@ietf.org mailing list should use >>>> an appropriate subject, such as "Request for PKCE >>>> code_challenge_method: example"). >>>> >>>> The Designated Expert(s) should consider the discussion on the >>>> mailing list, as well as <> when evaluating >>>> registration requests. Denials should include an explanation >>>> and, if applicable, suggestions as to how to make the request >>>> successful. >>>> END >>> >>> Thanks. The editors were just trying to be consistent with the way the >>> parent spec was dealing with this kind of things, but if the suggested = way >>> is preferred, we can certainly do it. >> >> Thanks! >> >>>> -- Section 7.2 -- >>>> Please rewrite the first paragraph. Please do not leave it for the RF= C >>>> Editor, as they may inadvertently get it technically wrong when they t= ry > From nobody Thu Jun 11 06:16:47 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09311AD06B; Thu, 11 Jun 2015 06:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 LtKkfSvLhiKw; Thu, 11 Jun 2015 06:16:37 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 13A061ACEF6; Thu, 11 Jun 2015 06:16:37 -0700 (PDT) Received: by oihd6 with SMTP id d6so3770433oih.2; Thu, 11 Jun 2015 06:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tphZBAkiadnLfhy+JNeIlnQW+C8jdaOzybwfv5bnXSQ=; b=amc488CLSVos8xlSGOfaDeoy+vowW7j4nRx3Nm0vG2QvKCZeTdOKnAZa227YqEESAV J+E24ISEZ6UhP0yYk9Pm/sxQp/dD5Yv8Vb4vDLJvJFlby/UJZ6FCIKZmNXCEL9fW4CPV yTE87jX86Hi15cO5WqrVsktLNB9RITGkADh6/ClwJDw+Iw1y1AdLv6qaJU9kNVE+LHDx INuplOCcun9Ht2CjApDVS6/KlUAMMB5GDRC57ude4j3f3xuiPiB87jWvVeXpkTWq++oq rNY4auNf23rrJ02AH6pR4+3T6ggQjN3iercIQ5OuAVpWd0Dan8eiTGakZqJoPZwvVi35 XkFw== MIME-Version: 1.0 X-Received: by 10.202.178.70 with SMTP id b67mr7029304oif.0.1434028596408; Thu, 11 Jun 2015 06:16:36 -0700 (PDT) Received: by 10.60.164.97 with HTTP; Thu, 11 Jun 2015 06:16:36 -0700 (PDT) In-Reply-To: References: <20150608194249.3968.61933.idtracker@ietfa.amsl.com> <36D1546CCAE1477491A4FF9FBA8D2FF2@NatCFRZ4> <34824FDE-F0F8-4AD8-8824-3417B40C50C1@ve7jtb.com> Date: Thu, 11 Jun 2015 22:16:36 +0900 Message-ID: From: Nat Sakimura To: Barry Leiba Content-Type: multipart/alternative; boundary=001a113cd1881639a105183dcd61 Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth WG , draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 13:16:43 -0000 --001a113cd1881639a105183dcd61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed, "plain" is for "on-boarding" the current implementations and developers. S256 is the way forward. We added intro pretty late to describe what John stated "nicely". Apparently it did not quite work as questions came around. We probably should bolster the intro. Nat 2015-06-11 21:54 GMT+09:00 Barry Leiba : > John, thanks *very* much for this detailed background -- it's really > helpful, and particularly helpful to get it before the telechat > discussion. > > Given what you say, I still prefer the "no plain" path, because the > inability to steal the challenge depends upon current OS > implementations. That said, I'm much more open to accepting the > current situation with the understanding that S256 is the path > forward, and that plain is there to support existing use cases and > deployment. It would be really good if some of this detail could be > put into the Introduction so that readers can understand (1) why we're > where we are and (2) why we should stop using plain for new > situations, and stick with S256. > > So let's see where the discussion goes on the telechat. > > Barry > > On Thu, Jun 11, 2015 at 1:45 PM, John Bradley wrote: > > Hi Barry, > > > > > > The main attack and the origin of the spec is caused by a native app on > the device overloading the intent URI/custom scheme > > that the legitimate OAuth client has registered as it=E2=80=99s redirec= t_uri. > > > > The request path travels from the legitimate app to the system browser > by a secure API call, and can=E2=80=99t be intercepted unless the attacke= r can > replace the system browser. > > The browser then sends the request to the Authorization endpoint over > TLS per OAuth. That again would require a TLS man in the middle to > compromise and is no more a concern than any other use of TLS. > > > > The AS formulates it=E2=80=99s response and sends it back to the browse= r over > TLS as a 302. That again is fine and not a special concern. > > The attack comes when the browser uses the location header to call back > that native app on the device. > > > > Because of the nature of intent URI multiple apps can register the same > scheme, so are eligible to receive the response. > > On Android if there is more than one receiver registered the user is > prompted for what app they want invoked. > > There is always a chance that the user will select the wrong app and th= e > attacker gets the Authorization Code. > > > > On iOS the selection behaviour depends on the version , in some version= s > it just random, others select the most recently run app. > > iOS 8 is random so an attacker has about a 50% chance of success in > intercepting the Authorization Code. > > > > The attack opportunity is only present in the response path, because th= e > way that the OS expose the API call to invoke the system browser is > diffrent from the way the system browser invokes the callback to a native > app. > > > > Given this we came up with the plain transform that requires no crypto > that no developer has an excuse for not using all the time. > > > > The code_challenge isn=E2=80=99t vulnerable to interception because it = is sent > with a different API in the device. > > The response containing the code has something like a 50% chance of > interception in the response, but doesn=E2=80=99t contain the code_challe= nge. > > > > This attack being against a OS API method and not on the wire is why we > missed it in the OAuth spec. > > > > The plain transform is effective against this attack as the > communication of the code_challenge from the client to the AS is over a > secure API and TLS. > > > > The second attack is the one we don=E2=80=99t know about yet. It may b= e a > buffer leak in the OS or a weakness in the deployment that allows the > system browser to use SSL with a weak > > alg that could be sniffed. I just don=E2=80=99t know, but as most peo= ple > realize that I am an exceptionally paranoid person > > (Your gov is really watching me, I saw the DHS powerpoint. It is quite > funny, nice to have friends.) > > > > I insisted in including the S256 transform for all the other attacks, a= s > it is not much more complicated and if you can protect against sniffing o= f > the request then a reasonable person would do it. The specs I am working > on that use PKCE have S256 as a MUST. > > > > So I talked the WG and deployers into putting S256 into the core PKCE > spec rather than having it as an extension as it was originally so that i= t > could be MTI for servers to implement. > > > > If we remove plain completely from the spec now, i may become the Googl= e > equivalent of disappeared, as them agreeing to put S256 in has lead to th= is. > > > > Keeping plain but changing code_challenge_method if not present to the > default of S256 will break existing deployments with PKCE standard client= s, > or all the current clients without deploying new authorization endpoints. > > That would not be good for adoption. > > > > A compromise that might work for people would be making > code_challenge_method required, and removing the default language. > > > > That way we can say that the server MUST support S256, and that the > client SHOULD use S256. > > > > plain is for backwards compatibility, and for constrained environments > that are unable to do SHA256. > > > > If an attacker can modify the request, all they need to do is remove th= e > code_challenge to get around this unless the client has used client > registration to lock down a required > > code_challenge_method, so we are not introducing a downgrade attack by > having plain that is not available to an attacker by removing PKCE entire= ly > from the request. > > > > Unfortunately this week is CIS for me and I am having a hard time > keeping up with email. > > > > Let me know what you think. > > > > I agree that we want to direct developers to S256 as the preference, bu= t > that only works if we get AS to deploy it, and developers to use it. > > > > John B. > > > > > > > > > >> On Jun 11, 2015, at 3:35 AM, Barry Leiba > wrote: > >> > >> Hi, Nat, and thanks for the reply. > >> > >>>> How does "plain" do anything at all to mitigate this attack? Wouldn= 't > >>>> anyone who could snag the grant also be able to snag the code > verifier as > >>>> well? Why is "plain" even here? > >>> > >>> You have to understand that this spec deals with a scenario that the > >>> communication is conducted over two segments: > >>> (1) Unprotected: Within the machine through mechanisms like custom > >>> scheme. > >>> (2) Protected: Over the network, which is protected by TLS. > >>> > >>> The =E2=80=9Csnagging=E2=80=9D happens over the segment (1). For exam= ple, an attacker > can > >>> snag the grant over this segment. > >>> > >>> However, he cannot snag code verifier because it is sent over (2), > which is > >>> TLS protected. > >> > >> Well, the code verifier isn't sent at all, as I understand the > >> protocol. It's the transformed version, the challenge, that's sent. > >> Am I right? > >> > >> Now, you appear to be telling me that the challenge (and method) that > >> are sent in Section 4.3 and the Authorization Response that is sent in > >> Section 4.4 are sent in different ways (though you don't say that in > >> the document), and that the transmission in 4.4 is open to > >> interception, but the transmission in 4.3 is not. Is that an accurate > >> summary? > >> > >> If it is correct that the transmission that's described in 4.3 can > >> *never* be intercepted, then I'm a bit less worried about "plain". > >> > >> But given the simplicity of implementing S256: > >> > >> 1. If there's *any* possibility of interception in some scenarios, I > >> still strongly oppose having "plain" at all, because if it's there, > >> it's bound to be used when it shouldn't have been. > >> > >> 2. I don't buy the argument that it's OK to build a weaker protocol > >> because implementors think that weak is good enough. I think we need > >> to use our best protocol design principles and make sure what we > >> publish as "standard" is what we think reflects the best protocol > >> design. > >> > >> On to the less strenuous stuff... > >> > >>>> General: > >>>> I would think that this mechanism should never be a substitute for > using > >>>> TLS, and that this document should be explicit about that, and shoul= d > say > >>>> that the proper mitigation for situations where TLS can be used... i= s > to > >>>> use TLS. Is there a reason we should NOT say that? > >>> > >>> OAuth (RFC6749 and RFC6750) mandates the use of TLS over the network. > >>> PKCE inherits this property. We could mention it again here, but it i= s > sort > >>> of already done by inheritance. > >> > >> That's true. I'll leave this to your judgment, and no need for > >> further discussion. The reason I mentioned it was to make sure that > >> implementors don't think that this mechanism can be a substitute for > >> TLS. But if you think the OAuth specs are already solid enough on the > >> TLS thing, I'm OK with that. > >> > >>>> Putting quotation marks around "code_verifier" and "code_challenge" = in > >>>> the formulas is confusing: it makes it look as if you're putting in > those > >>>> strings themselves, rather than the values of the variables. It's > >>>> probably unlikely that anyone would make that mistake, but I > nevertheless > >>>> suggest removing the quotation marks when you mean to refer to the > >>>> values. > >>> > >>> That=E2=80=99s the peculiarity of the current XML2TXT converter. > >>> In XML, it is to signify strings themselves > rather than > >>> the values of the variables. > >>> It renders nicely on HTML format etc., but TXT seem to have this > confusing > >>> property. > >>> Perhaps RFC Editor can deal with. > >> > >> I don't understand that. When you say, for example: > >> > >> "code_verifier" =3D=3D "code_challenge" > >> > >> and > >> > >> BASE64URL-ENCODE(SHA256(ASCII("code_verifier" ))) > >> =3D=3D "code_challenge" > >> > >> ...you are not referring to the strings, but to the values, so why are > >> you marking them up at all? They should just be this way: > >> > >> code_verifier =3D=3D code_challenge > >> > >> and > >> > >> BASE64URL-ENCODE(SHA256(code_verifier)) > >> =3D=3D code_challenge > >> > >> (see below about the "ASCII()" thing), with no markup causing quotatio= n > marks. > >> > >> Or maybe I misunderstand what you're saying. And, no, I don't think > >> we can leave it to the RFC Editor, unless we're quite explicit (with a > >> note in the document) about telling them exactly what we want them to > >> do. > >> > >>>> -- Section 2 -- > >>>> I don't understand the distinction between STRING and ASCII(STRING). > Can > >>>> you please explain it? > >>> > >>> It is a notation used by JSON Web Signature, etc. > >>> It is making sure not to conflate the sequence of characters with > sequence > >>> of octets of characters. > >> > >> You already define "STRING" as a sequence of ASCII characters (and you > >> have "OCTETS" for arbitrary non-character octets). ASCII is already a > >> character encoding. So there's no need to say that you have to take > >> characters that are represented in ASCII, and represent them in ASCII. > >> It's redundant, and it adds clutter. > >> > >> Of course, it's also not wrong, so this is not a DISCUSS, and you can > >> do as you think best. I just suggest removing the "ASCII()" > >> throughout, as it's totally unnecessary, and, as I say, it adds > >> clutter. I'll note that your definition of "ASCII(STRING)" is quite > >> convoluted, and the reason it's convoluted is that you have to twist > >> yourself around a pole to make definition that says anything other > >> than "ASCII(STRING) is just STRING". > >> > >>>> -- Section 4.3 -- > >>>> If "plain" does stay, why on Earth is it the default? Even if just > for > >>>> form's sake, shouldn't S256 be the default? > >>> > >>> It is partly historical. The draft started off there, then kept addin= g > other > >>> mechanisms. There are many implementations of PKCE now but the larges= t > >>> portion of it is using =E2=80=9Cplain=E2=80=9D. For the sake of inter= operability with > them, > >>> it needs to stay as it is written. > >> > >> In other words, if you change the default then existing > >> implementations will have to change to match. I get that, but, again, > >> we shouldn't be making our protocols suboptimal for that reason. I'd > >> rather see us eliminate "plain" altogether, so I won't argue this > >> further on this point. > >> > >>>> -- Section 4.4 -- > >>>> The word "code" is used for too many things, and "Authorization > Grant" is > >>>> already the right name for what we're talking about here. I suggest > that > >>>> in both the section title and body you use that term, to make it cle= ar > >>>> what you mean by the "code". > >>> > >>> RFC 6749 defines two types of Authorization Grant: Authorization Code > and > >>> Implicit. In PKCE, we are specifically dealing with Authorization Cod= e > so > >>> replacing them with Authorization Grant loosens it up and is not > desirable. > >>> I agree that we have been a bit lax in the use of the term =E2=80=9Cc= ode=E2=80=9D as an > >>> abbreviation of =E2=80=9CAuthorization Code=E2=80=9D. Also, looking a= t the TXT > >>> representation of the spec, largely due to the formatting peculiarity= , > it is > >>> making them even more confusing than compared to other format. > Therefore, I > >>> suggest the following: > >>> > >>> - Replace all occurrence of =E2=80=9Ccode=E2=80=9D as an abbreviation= of =E2=80=9CAuthorization > >>> Code=E2=80=9D with =E2=80=9CAuthorization Code=E2=80=9D. > >> > >> Perfect; thanks. > >> > >>> - Capitalize the defined term =E2=80=9Ccode challenge=E2=80=9D and = =E2=80=9Ccode verifier=E2=80=9D so > that > >>> there will become =E2=80=9CCode Challenge=E2=80=9D and =E2=80=9CCode = Verifier=E2=80=9D throughout. > >> > >> I like that too. > >> > >>>> -- Section 4.4.1 -- > >>>> Please expand "PKCE", which is, at the moment, only expanded in the > >>>> document title. > >>> > >>> Suggest the following: > >>> Replace =E2=80=9Cthis extension=E2=80=9D of the last paragraph of 1. = Introduction by > =E2=80=9CProof > >>> Key for Code Exchange (PKCE) extension=E2=80=9D. > >>> Add =E2=80=9C3.1 Abbreviation=E2=80=9D subsection and collect the abb= reviations that > are > >>> used in this specification, namely: > >>> - PKCE =E2=80=93 Proof Key for (Authorization) Code Exchange > >>> - Authz -- Authorization > >>> - App =E2=80=93 Application > >>> - MITM =E2=80=93 Man In The Middle > >> > >> That works well; thanks. > >> > >>> I guess we do not need to list IESG, IANA, and RFC in it=E2=80=A6 > >> > >> That's correct. The RFC Editor maintain a list of common > >> abbreviations, noting those that don't need expansion. See > >> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > >> (You can get this from the main RFC Editor page by clicking on "RFC > >> Style Guide", and then "Abbreviations List".) > >> > >>>> -- Section 5 -- > >>>> The SHOULD in the first paragraph is wrong. You already have a MAY > >>>> covering the general behavior. You should just take out the "SHOULD= ", > >>>> and just say that severs supporting backwards compatibility revert t= o > the > >>>> normal OAuth protocol. > >>> > >>> Accept in principle, but at the same time, I feel that explicitly > writing > >>> that the server is expected to fall back to RFC6749 and RFC6750 mode > without > >>> error probably is useful for developers. For this purpose, this > =E2=80=9CSHOULD=E2=80=9D > >>> while redundant, could be useful. Perhaps, just replacing =E2=80=9CSH= OULD=E2=80=9D with > >>> =E2=80=9Cshould=E2=80=9D suffice? > >> > >> Again, not a DISCUSS, so use judgment. I think even "should" is > >> totally unnecessary -- you're just saying how the protocol works. If > >> you want compatibility, this is what you do. Not what you "should" > >> do, but what you do in order to maintain compatibility. But no > >> further discussion needed here. > >> > >>>> -- Section 6.2 -- > >>>> I have the same comment here as in the other OAuth document: please > shift > >>>> the focus away from telling IANA how to handle tracking of the exper= t > >>>> review, and make the mailing list something that the designated > expert(s) > >>>> keep track of. Also, please give more instructions to the DEs about > what > >>>> they should consider when they're evaluating a request (for example, > >>>> should they approve all requests, or are there criteria they should > >>>> apply?). > >>>> > >>>> For the first, here's a text change that I suggest we move toward fo= r > >>>> this sort of thing: > >>>> > >>>> OLD > >>>> > >>>> > >>>> NEW > >>>> Additional code_challenge_method types for use with the > authorization > >>>> endpoint are registered using the Specification Required policy > >>>> [RFC5226], which includes review of the request by one or more > >>>> Designated Experts. The DEs will ensure there is at least a > two-week > >>>> review of the request on the oauth-ext-review@ietf.org mailing > list, > >>>> and that any discussion on that list converges before they respond > to > >>>> the request. To allow for the allocation of values prior to > >>>> publication, the Designated Expert(s) may approve registration onc= e > >>>> they are satisfied that an acceptable specification will be > >>>> published. > >>>> > >>>> Discussion on the oauth-ext-review@ietf.org mailing list should us= e > >>>> an appropriate subject, such as "Request for PKCE > >>>> code_challenge_method: example"). > >>>> > >>>> The Designated Expert(s) should consider the discussion on the > >>>> mailing list, as well as <> when evaluating > >>>> registration requests. Denials should include an explanation > >>>> and, if applicable, suggestions as to how to make the request > >>>> successful. > >>>> END > >>> > >>> Thanks. The editors were just trying to be consistent with the way th= e > >>> parent spec was dealing with this kind of things, but if the suggeste= d > way > >>> is preferred, we can certainly do it. > >> > >> Thanks! > >> > >>>> -- Section 7.2 -- > >>>> Please rewrite the first paragraph. Please do not leave it for the > RFC > >>>> Editor, as they may inadvertently get it technically wrong when they > try > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a113cd1881639a105183dcd61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indeed, "plain" is for "on-boarding" t= he current implementations and developers.=C2=A0
S256 is the way forwar= d.=C2=A0

We added intro pretty late to describe wh= at John stated "nicely". Apparently it did not quite work as ques= tions came around. We probably should bolster the intro.=C2=A0
Nat



2015-06-11 21:54 GMT+09:00 Barry L= eiba <barryleiba@computer.org>:
John, thanks *very* much for this detailed background -- it&#= 39;s really
helpful, and particularly helpful to get it before the telechat
discussion.

Given what you say, I still prefer the "no plain" path, because t= he
inability to steal the challenge depends upon current OS
implementations.=C2=A0 That said, I'm much more open to accepting the current situation with the understanding that S256 is the path
forward, and that plain is there to support existing use cases and
deployment.=C2=A0 It would be really good if some of this detail could be put into the Introduction so that readers can understand (1) why we're<= br> where we are and (2) why we should stop using plain for new
situations, and stick with S256.

So let's see where the discussion goes on the telechat.

Barry

On Thu, Jun 11, 2015 at 1:45 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> Hi Barry,
>
>
> The main attack and the origin of the spec is caused by a native app o= n the device overloading the intent URI/custom scheme
> that the legitimate OAuth client has registered as it=E2=80=99s redire= ct_uri.
>
> The request path travels from the legitimate app to the system browser= by a secure API call, and can=E2=80=99t be intercepted unless the attacker= can replace the system browser.
> The browser then sends the request to the Authorization endpoint over = TLS per OAuth.=C2=A0 That again would require a TLS man in the middle to co= mpromise and is no more a concern than any other use of TLS.
>
> The AS formulates it=E2=80=99s response and sends it back to the brows= er over TLS as a 302.=C2=A0 That again is fine and not a special concern. > The attack comes when the browser uses the location header to call bac= k that native app on the device.
>
> Because of the nature of intent URI multiple apps can register the sam= e scheme, so are eligible to receive the response.
> On Android if there is more than one receiver registered the user is p= rompted for what app they want invoked.
> There is always a chance that the user will select the wrong app and t= he attacker gets the Authorization Code.
>
> On iOS the selection behaviour depends on the version , in some versio= ns it just random, others select the most recently run app.
> iOS 8 is random so an attacker has about a 50% chance of success in in= tercepting the Authorization Code.
>
> The attack opportunity is only present in the response path, because t= he way that the OS expose the API call to invoke the system browser is diff= rent from the way the system browser invokes the callback to a native app.<= br> >
> Given this we came up with the plain transform that requires no crypto= that no developer has an excuse for not using all the time.
>
> The code_challenge isn=E2=80=99t vulnerable to interception because it= is sent with a different API in the device.
> The response containing the code has something like a 50% chance of in= terception in the response, but doesn=E2=80=99t contain the code_challenge.=
>
> This attack being against a OS API method and not on the wire is why w= e missed it in the OAuth spec.
>
> The plain transform is effective against this attack as the communicat= ion of the code_challenge from the client to the AS is over a secure API an= d TLS.
>
> The second attack is the one we don=E2=80=99t know about yet.=C2=A0 It= may be a buffer leak in the OS or a weakness in the deployment that allows= the system browser to use SSL with a weak
> alg that could be sniffed.=C2=A0 =C2=A0I just don=E2=80=99t know, but = as most people realize that I am an exceptionally paranoid person
> (Your gov is really watching me, I saw the DHS powerpoint.=C2=A0 It is= quite funny, nice to have friends.)
>
> I insisted in including the S256 transform for all the other attacks, = as it is not much more complicated and if you can protect against sniffing = of the request then a reasonable person would do it.=C2=A0 The specs I am w= orking on that use PKCE have S256 as a MUST.
>
> So I talked the WG and deployers into putting S256 into the core PKCE = spec rather than having it as an extension as it was originally so that it = could be MTI for servers to implement.
>
> If we remove plain completely from the spec now, i may become the Goog= le equivalent of disappeared, as them agreeing to put S256 in has lead to t= his.
>
> Keeping plain but changing code_challenge_method if not present to the= default of S256 will break existing deployments with PKCE standard clients= , or all the current clients without deploying new authorization endpoints.=
> That would not be good for adoption.
>
> A compromise that might work for people would be making code_challenge= _method required, and removing the default language.
>
> That way we can say that the server MUST support S256, and that the cl= ient SHOULD use S256.
>
> plain is for backwards compatibility, and for constrained environments= that are unable to do SHA256.
>
> If an attacker can modify the request, all they need to do is remove t= he code_challenge to get around this unless the client has used client regi= stration to lock down a required
> code_challenge_method, so we are not introducing a downgrade attack by= having plain that is not available to an attacker by removing PKCE entirel= y from the request.
>
> Unfortunately this week is CIS for me and I am having a hard time keep= ing up with email.
>
> Let me know what you think.
>
> I agree that we want to direct developers to S256 as the preference, b= ut that only works if we get AS to deploy it, and developers to use it.
>
> John B.
>
>
>
>
>> On Jun 11, 2015, at 3:35 AM, Barry Leiba <barryleiba@computer.org> wrote:
>>
>> Hi, Nat, and thanks for the reply.
>>
>>>> How does "plain" do anything at all to mitigate = this attack?=C2=A0 Wouldn't
>>>> anyone who could snag the grant also be able to snag the c= ode verifier as
>>>> well?=C2=A0 Why is "plain" even here?
>>>
>>> You have to understand that this spec deals with a scenario th= at the
>>> communication is conducted over two segments:
>>> (1)=C2=A0 =C2=A0 Unprotected: Within the machine through mecha= nisms like custom
>>> scheme.
>>> (2)=C2=A0 =C2=A0 Protected: Over the network, which is protect= ed by TLS.
>>>
>>> The =E2=80=9Csnagging=E2=80=9D happens over the segment (1). F= or example, an attacker can
>>> snag the grant over this segment.
>>>
>>> However, he cannot snag code verifier because it is sent over = (2), which is
>>> TLS protected.
>>
>> Well, the code verifier isn't sent at all, as I understand the=
>> protocol.=C2=A0 It's the transformed version, the challenge, t= hat's sent.
>> Am I right?
>>
>> Now, you appear to be telling me that the challenge (and method) t= hat
>> are sent in Section 4.3 and the Authorization Response that is sen= t in
>> Section 4.4 are sent in different ways (though you don't say t= hat in
>> the document), and that the transmission in 4.4 is open to
>> interception, but the transmission in 4.3 is not.=C2=A0 Is that an= accurate
>> summary?
>>
>> If it is correct that the transmission that's described in 4.3= can
>> *never* be intercepted, then I'm a bit less worried about &quo= t;plain".
>>
>> But given the simplicity of implementing S256:
>>
>> 1. If there's *any* possibility of interception in some scenar= ios, I
>> still strongly oppose having "plain" at all, because if = it's there,
>> it's bound to be used when it shouldn't have been.
>>
>> 2. I don't buy the argument that it's OK to build a weaker= protocol
>> because implementors think that weak is good enough.=C2=A0 I think= we need
>> to use our best protocol design principles and make sure what we >> publish as "standard" is what we think reflects the best= protocol
>> design.
>>
>> On to the less strenuous stuff...
>>
>>>> General:
>>>> I would think that this mechanism should never be a substi= tute for using
>>>> TLS, and that this document should be explicit about that,= and should say
>>>> that the proper mitigation for situations where TLS can be= used... is to
>>>> use TLS.=C2=A0 Is there a reason we should NOT say that? >>>
>>> OAuth (RFC6749 and RFC6750) mandates the use of TLS over the n= etwork.
>>> PKCE inherits this property. We could mention it again here, b= ut it is sort
>>> of already done by inheritance.
>>
>> That's true.=C2=A0 I'll leave this to your judgment, and n= o need for
>> further discussion.=C2=A0 The reason I mentioned it was to make su= re that
>> implementors don't think that this mechanism can be a substitu= te for
>> TLS.=C2=A0 But if you think the OAuth specs are already solid enou= gh on the
>> TLS thing, I'm OK with that.
>>
>>>> Putting quotation marks around "code_verifier" a= nd "code_challenge" in
>>>> the formulas is confusing: it makes it look as if you'= re putting in those
>>>> strings themselves, rather than the values of the variable= s.=C2=A0 It's
>>>> probably unlikely that anyone would make that mistake, but= I nevertheless
>>>> suggest removing the quotation marks when you mean to refe= r to the
>>>> values.
>>>
>>> That=E2=80=99s the peculiarity of the current XML2TXT converte= r.
>>> In XML, it is <spanx style=3D"verb"> to signif= y strings themselves rather than
>>> the values of the variables.
>>> It renders nicely on HTML format etc., but TXT seem to have th= is confusing
>>> property.
>>> Perhaps RFC Editor can deal with.
>>
>> I don't understand that.=C2=A0 When you say, for example:
>>
>>=C2=A0 =C2=A0"code_verifier" =3D=3D "code_challenge&= quot;
>>
>> and
>>
>>=C2=A0 =C2=A0BASE64URL-ENCODE(SHA256(ASCII("code_verifier"= ; )))
>>=C2=A0 =C2=A0 =C2=A0 =3D=3D "code_challenge"
>>
>> ...you are not referring to the strings, but to the values, so why= are
>> you marking them up at all?=C2=A0 They should just be this way: >>
>>=C2=A0 =C2=A0code_verifier =3D=3D code_challenge
>>
>> and
>>
>>=C2=A0 =C2=A0BASE64URL-ENCODE(SHA256(code_verifier))
>>=C2=A0 =C2=A0 =C2=A0 =3D=3D code_challenge
>>
>> (see below about the "ASCII()" thing), with no markup ca= using quotation marks.
>>
>> Or maybe I misunderstand what you're saying.=C2=A0 And, no, I = don't think
>> we can leave it to the RFC Editor, unless we're quite explicit= (with a
>> note in the document) about telling them exactly what we want them= to
>> do.
>>
>>>> -- Section 2 --
>>>> I don't understand the distinction between STRING and = ASCII(STRING).=C2=A0 Can
>>>> you please explain it?
>>>
>>> It is a notation used by JSON Web Signature, etc.
>>> It is making sure not to conflate the sequence of characters w= ith sequence
>>> of octets of characters.
>>
>> You already define "STRING" as a sequence of ASCII chara= cters (and you
>> have "OCTETS" for arbitrary non-character octets).=C2=A0= ASCII is already a
>> character encoding.=C2=A0 So there's no need to say that you h= ave to take
>> characters that are represented in ASCII, and represent them in AS= CII.
>> It's redundant, and it adds clutter.
>>
>> Of course, it's also not wrong, so this is not a DISCUSS, and = you can
>> do as you think best.=C2=A0 I just suggest removing the "ASCI= I()"
>> throughout, as it's totally unnecessary, and, as I say, it add= s
>> clutter.=C2=A0 I'll note that your definition of "ASCII(S= TRING)" is quite
>> convoluted, and the reason it's convoluted is that you have to= twist
>> yourself around a pole to make definition that says anything other=
>> than "ASCII(STRING) is just STRING".
>>
>>>> -- Section 4.3 --
>>>> If "plain" does stay, why on Earth is it the def= ault?=C2=A0 Even if just for
>>>> form's sake, shouldn't S256 be the default?
>>>
>>> It is partly historical. The draft started off there, then kep= t adding other
>>> mechanisms. There are many implementations of PKCE now but the= largest
>>> portion of it is using =E2=80=9Cplain=E2=80=9D. For the sake o= f interoperability with them,
>>> it needs to stay as it is written.
>>
>> In other words, if you change the default then existing
>> implementations will have to change to match.=C2=A0 I get that, bu= t, again,
>> we shouldn't be making our protocols suboptimal for that reaso= n.=C2=A0 I'd
>> rather see us eliminate "plain" altogether, so I won'= ;t argue this
>> further on this point.
>>
>>>> -- Section 4.4 --
>>>> The word "code" is used for too many things, and= "Authorization Grant" is
>>>> already the right name for what we're talking about he= re.=C2=A0 I suggest that
>>>> in both the section title and body you use that term, to m= ake it clear
>>>> what you mean by the "code".
>>>
>>> RFC 6749 defines two types of Authorization Grant: Authorizati= on Code and
>>> Implicit. In PKCE, we are specifically dealing with Authorizat= ion Code so
>>> replacing them with Authorization Grant loosens it up and is n= ot desirable.
>>> I agree that we have been a bit lax in the use of the term =E2= =80=9Ccode=E2=80=9D as an
>>> abbreviation of =E2=80=9CAuthorization Code=E2=80=9D. Also, lo= oking at the TXT
>>> representation of the spec, largely due to the formatting pecu= liarity, it is
>>> making them even more confusing than compared to other format.= Therefore, I
>>> suggest the following:
>>>
>>> - Replace all occurrence of =E2=80=9Ccode=E2=80=9D as an abbre= viation of =E2=80=9CAuthorization
>>> Code=E2=80=9D with =E2=80=9CAuthorization Code=E2=80=9D.
>>
>> Perfect; thanks.
>>
>>> - Capitalize the defined term =E2=80=9Ccode challenge=E2=80=9D= and =E2=80=9Ccode verifier=E2=80=9D so that
>>> there will become =E2=80=9CCode Challenge=E2=80=9D and =E2=80= =9CCode Verifier=E2=80=9D throughout.
>>
>> I like that too.
>>
>>>> -- Section 4.4.1 --
>>>> Please expand "PKCE", which is, at the moment, o= nly expanded in the
>>>> document title.
>>>
>>> Suggest the following:
>>> Replace =E2=80=9Cthis extension=E2=80=9D of the last paragraph= of 1. Introduction by =E2=80=9CProof
>>> Key for Code Exchange (PKCE) extension=E2=80=9D.
>>> Add =E2=80=9C3.1 Abbreviation=E2=80=9D subsection and collect = the abbreviations that are
>>> used in this specification, namely:
>>> - PKCE =E2=80=93 Proof Key for (Authorization) Code Exchange >>> - Authz -- Authorization
>>> - App =E2=80=93 Application
>>> - MITM =E2=80=93 Man In The Middle
>>
>> That works well; thanks.
>>
>>> I guess we do not need to list IESG, IANA, and RFC in it=E2=80= =A6
>>
>> That's correct.=C2=A0 The RFC Editor maintain a list of common=
>> abbreviations, noting those that don't need expansion.=C2=A0 S= ee
>> http://www.rfc-editor.org/rfc-style-guide/abbrev= .expansion.txt
>> (You can get this from the main RFC Editor page by clicking on &qu= ot;RFC
>> Style Guide", and then "Abbreviations List".)
>>
>>>> -- Section 5 --
>>>> The SHOULD in the first paragraph is wrong.=C2=A0 You alre= ady have a MAY
>>>> covering the general behavior.=C2=A0 You should just take = out the "SHOULD",
>>>> and just say that severs supporting backwards compatibilit= y revert to the
>>>> normal OAuth protocol.
>>>
>>> Accept in principle, but at the same time, I feel that explici= tly writing
>>> that the server is expected to fall back to RFC6749 and RFC675= 0 mode without
>>> error probably is useful for developers. For this purpose, thi= s =E2=80=9CSHOULD=E2=80=9D
>>> while redundant, could be useful. Perhaps, just replacing =E2= =80=9CSHOULD=E2=80=9D with
>>> =E2=80=9Cshould=E2=80=9D suffice?
>>
>> Again, not a DISCUSS, so use judgment.=C2=A0 I think even "sh= ould" is
>> totally unnecessary -- you're just saying how the protocol wor= ks.=C2=A0 If
>> you want compatibility, this is what you do.=C2=A0 Not what you &q= uot;should"
>> do, but what you do in order to maintain compatibility.=C2=A0 But = no
>> further discussion needed here.
>>
>>>> -- Section 6.2 --
>>>> I have the same comment here as in the other OAuth documen= t: please shift
>>>> the focus away from telling IANA how to handle tracking of= the expert
>>>> review, and make the mailing list something that the desig= nated expert(s)
>>>> keep track of.=C2=A0 Also, please give more instructions t= o the DEs about what
>>>> they should consider when they're evaluating a request= (for example,
>>>> should they approve all requests, or are there criteria th= ey should
>>>> apply?).
>>>>
>>>> For the first, here's a text change that I suggest we = move toward for
>>>> this sort of thing:
>>>>
>>>> OLD
>>>> <most of Section 6.2>
>>>>
>>>> NEW
>>>>=C2=A0 =C2=A0Additional code_challenge_method types for use= with the authorization
>>>>=C2=A0 =C2=A0endpoint are registered using the Specificatio= n Required policy
>>>>=C2=A0 =C2=A0[RFC5226], which includes review of the reques= t by one or more
>>>>=C2=A0 =C2=A0Designated Experts.=C2=A0 The DEs will ensure = there is at least a two-week
>>>>=C2=A0 =C2=A0review of the request on the oauth-ext-review@ietf.org mailing list,
>>>>=C2=A0 =C2=A0and that any discussion on that list converges= before they respond to
>>>>=C2=A0 =C2=A0the request.=C2=A0 To allow for the allocation= of values prior to
>>>>=C2=A0 =C2=A0publication, the Designated Expert(s) may appr= ove registration once
>>>>=C2=A0 =C2=A0they are satisfied that an acceptable specific= ation will be
>>>> published.
>>>>
>>>>=C2=A0 =C2=A0Discussion on the oauth-ext-review@ietf.org mailing list should use
>>>>=C2=A0 =C2=A0an appropriate subject, such as "Request = for PKCE
>>>>=C2=A0 =C2=A0code_challenge_method: example").
>>>>
>>>>=C2=A0 =C2=A0The Designated Expert(s) should consider the d= iscussion on the
>>>>=C2=A0 =C2=A0mailing list, as well as <<these other t= hings>> when evaluating
>>>>=C2=A0 =C2=A0registration requests.=C2=A0 Denials should in= clude an explanation
>>>>=C2=A0 =C2=A0and, if applicable, suggestions as to how to m= ake the request
>>>>=C2=A0 =C2=A0successful.
>>>> END
>>>
>>> Thanks. The editors were just trying to be consistent with the= way the
>>> parent spec was dealing with this kind of things, but if the s= uggested way
>>> is preferred, we can certainly do it.
>>
>> Thanks!
>>
>>>> -- Section 7.2 --
>>>> Please rewrite the first paragraph.=C2=A0 Please do not le= ave it for the RFC
>>>> Editor, as they may inadvertently get it technically wrong= when they try
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
=
Nat Sakimura (=3Dnat)
Chairman, OpenID F= oundation
http://= nat.sakimura.org/
@_nat_en
--001a113cd1881639a105183dcd61-- From nobody Thu Jun 11 07:17:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BB11B29A8; Thu, 11 Jun 2015 07:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 xt6L5asTxZqN; Thu, 11 Jun 2015 07:17:10 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 BE5811B29A7; Thu, 11 Jun 2015 07:17:09 -0700 (PDT) Received: by wiwd19 with SMTP id d19so75773600wiw.0; Thu, 11 Jun 2015 07:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8qjJs18ldTDAs1BZzwlXrYX8ziXgA5mm+8zaH1/N15U=; b=o7DAkX0u/woSezZ5+IsS4fI437UT3LmP4tVTl6VuhWXIbiXiRS5rcN0tMSuY1n0uUV 9XQwJ94d1uGri1gv3wqbPkj5LKLOM3w+6UbPSyp+PDomIMemukXJBB3h4hSEkptIIxK7 4btjy6/AuHqAR1UG21wy2FfEgDrImPnAsPoNtIyGZN47F7E8acHHGU4RSItPFDhSHfH3 ACjrhb1CHJNiSVof77gwFB+EHW69GZfAQPai4zACpJDcjEhXSgPOLyFpujTJSY4njmm/ nWQukrTH5oBxKzZ+vdkUN0OVjlgDDSOyTWe3sCRYjeAaYPEjS1mZKYnRlMLrd9rT6Swo hrdg== MIME-Version: 1.0 X-Received: by 10.194.222.230 with SMTP id qp6mr17307807wjc.70.1434032228519; Thu, 11 Jun 2015 07:17:08 -0700 (PDT) Received: by 10.28.148.148 with HTTP; Thu, 11 Jun 2015 07:17:08 -0700 (PDT) In-Reply-To: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> References: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 10:17:08 -0400 Message-ID: From: Kathleen Moriarty To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a11c3bad893d7c105183ea530 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, "oauth@ietf.org" , draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , oauth-chairs@ietf.org Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 14:17:12 -0000 --001a11c3bad893d7c105183ea530 Content-Type: text/plain; charset=UTF-8 Hi, I haven't seen a response on this yet. Please respond to discuss the issues pointed out by Alissa. Thank you, Kathleen On Mon, Jun 8, 2015 at 12:40 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-oauth-introspection-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > = Section 2.1 = > "The endpoint MAY allow other parameters to provide further context to > the query. For instance, an authorization service may need to know > the IP address of the client accessing the protected resource in > order to determine the appropriateness of the token being presented." > > How does the protected resource know whether it needs to include such > additional parameters or not? What is meant by the "appropriateness" of > the token? > > In general if we're talking about a piece of data that could be sensitive > like client IP address, it would be better for there to be specific > guidelines to direct protected resources as to when this information > needs to be sent. I note that Section 5 basically says such > considerations are out of scope, but if this specific example is to be > provided here then they seem in scope to me. > > = Section 5 = > "One way to limit disclosure is to require > authorization to call the introspection endpoint and to limit calls > to only registered and trusted protected resource servers." > > I thought Section 2.1 made authorization to call the introspection > endpoint mandatory. This makes it sound like it's optional. Which is it? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > = Section 1.1 = > There is no reference to RFC2119 here, which may be okay but most > documents include it if they use normative language (I think). > > = Section 2 = > "The > definition of an active token is up to the authorization server, but > this is commonly a token that has been issued by this authorization > server, is not expired, has not been revoked, and is within the > purview of the protected resource making the introspection call." > > Is "within the purview" a term of art for OAuth 2.0? Is there a more > specific way to describe what is meant here? Also, I note that in the > description of the "active" member in Section 2.2, this criterion is not > listed. It seems like these should be aligned. > > = Section 2.2 = > "Note that in order to avoid disclosing too much of the > authorization server's state to a third party, the authorization > server SHOULD NOT include any additional information about an > inactive token, including why the token is inactive." > > Seems like this should be a MUST NOT unless there's some reason for > providing anything other than active set to false. Same comment applies > in Section 4. > > = Section 2.3 = > It seems like there is another error condition and I'm wondering if its > handling needs to be specified. Per my question in Section 2.1, if it's > possible that the request is properly formed but is missing some > additional information that the authorization server needs to evaluate > it, should there be an error condition specified for that case? > > > -- Best regards, Kathleen --001a11c3bad893d7c105183ea530 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I haven't seen a response on th= is yet.=C2=A0 Please respond to discuss the issues pointed out by Alissa.

Thank you,
Kathleen

On Mon, Jun 8, 2015 at 12:4= 0 PM, Alissa Cooper <alissa@cooperw.in> wrote:
Alissa Cooper has entered the following ballot positio= n for
draft-ietf-oauth-introspection-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-oauth-introspection/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

=3D Section 2.1 =3D
"The endpoint MAY allow other parameters to provide further context to=
=C2=A0 =C2=A0the query.=C2=A0 For instance, an authorization service may ne= ed to know
=C2=A0 =C2=A0the IP address of the client accessing the protected resource = in
=C2=A0 =C2=A0order to determine the appropriateness of the token being pres= ented."

How does the protected resource know whether it needs to include such
additional parameters or not? What is meant by the "appropriateness&qu= ot; of
the token?

In general if we're talking about a piece of data that could be sensiti= ve
like client IP address, it would be better for there to be specific
guidelines to direct protected resources as to when this information
needs to be sent. I note that Section 5 basically says such
considerations are out of scope, but if this specific example is to be
provided here then they seem in scope to me.

=3D Section 5 =3D
"One way to limit disclosure is to require
=C2=A0 =C2=A0authorization to call the introspection endpoint and to limit = calls
=C2=A0 =C2=A0to only registered and trusted protected resource servers.&quo= t;

I thought Section 2.1 made authorization to call the introspection
endpoint mandatory. This makes it sound like it's optional. Which is it= ?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

=3D Section 1.1 =3D
There is no reference to RFC2119 here, which may be okay but most
documents include it if they use normative language (I think).

=3D Section 2 =3D
"The
=C2=A0 =C2=A0definition of an active token is up to the authorization serve= r, but
=C2=A0 =C2=A0this is commonly a token that has been issued by this authoriz= ation
=C2=A0 =C2=A0server, is not expired, has not been revoked, and is within th= e
=C2=A0 =C2=A0purview of the protected resource making the introspection cal= l."

Is "within the purview" a term of art for OAuth 2.0? Is there a m= ore
specific way to describe what is meant here? Also, I note that in the
description of the "active" member in Section 2.2, this criterion= is not
listed. It seems like these should be aligned.

=3D Section 2.2 =3D
"Note that in order to avoid disclosing too much of the
=C2=A0 =C2=A0authorization server's state to a third party, the authori= zation
=C2=A0 =C2=A0server SHOULD NOT include any additional information about an<= br> =C2=A0 =C2=A0inactive token, including why the token is inactive."

Seems like this should be a MUST NOT unless there's some reason for
providing anything other than active set to false. Same comment applies
in Section 4.

=3D Section 2.3 =3D
It seems like there is another error condition and I'm wondering if its=
handling needs to be specified. Per my question in Section 2.1, if it's=
possible that the request is properly formed but is missing some
additional information that the authorization server needs to evaluate
it, should there be an error condition specified for that case?





--

Best regards,
Kath= leen
--001a11c3bad893d7c105183ea530-- From nobody Thu Jun 11 11:49:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9981B2C89; Thu, 11 Jun 2015 11:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 l-fqLjHeKp1q; Thu, 11 Jun 2015 11:49:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 899DD1B2C86; Thu, 11 Jun 2015 11:49:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150611184955.1618.38149.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 11:49:55 -0700 Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 18:49:58 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-spop-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- After getting John's explanation of the background and details of the attack (and the different communications paths involved, I still would prefer that we build this protocol as a more robust one (with only S256 and not "plain"), but I understand the reasons to have it this way, and I think it will be acceptable with some changes to the text to make the situation clearer. To that end, I suggest this: In the introduction, I think the explanation of Figure 1 (the fourth paragraph) should be changed to make it clear what communication paths are used in each step, and where the vulnerable piece is. Something like this: OLD In step (1) the native app running on the end device, such as a smart phone, issues an authorization request via the browser/operating system, which then gets forwarded to the OAuth 2.0 authorization server in step (2). The authorization server returns the authorization code in step (3). The malicious app is able to observe the authorization code in step (4) since it is registered to the custom URI scheme used by the legitimate app. This allows the attacker to reguest and obtain an access token in step (5) and step (6), respectively. NEW In step (1) the native app running on the end device, such as a smart phone, issues an authorization request via the browser/operating system. The request includes a URI by which the response will be returned, and that uses a custom URI scheme. Step (1) happens through a secure API that cannot be intercepted. The request then gets forwarded to the OAuth 2.0 authorization server in step (2). Because OAuth requires the use of TLS, this communication is protected by TLS, and also cannot be intercepted. The authorization server returns the authorization code over the same TLS connection in step (3). In step (4), the Authorization Code is returned to the requester via the URI that was provided in step (1). A malicious app that has been designed to attack this native app has previously registered itself as a handler for the custom URI scheme, and is now able to observe the Authorization Code in step (4). This allows the attacker to request and obtain an access token in steps (5) and (6). END That (or something like it) makes it clear that only one step is vulnerable, and explicitly tells us that the other communication paths are already protected. In the list of pre-conditions, I suggest changing (1) to make "another application" be "a legitimate application that uses OAuth". *** IMPORTANT *** I am still puzzled by this, in pre-condition (4), which seems to contradict what John said and what I proposed above: 4) The attacker (via the installed app) is able to observe responses from the authorization endpoint. As a more sophisticated attack scenario the attacker is also able to observe requests (in addition to responses) to the authorization endpoint. Can you please explain the "more sophisticated attack", and how the attacker can observe the request? Because "plain" will NOT work in such a situation. I suggest changing the last paragraph in the Introduction like this: OLD To mitigate this attack, this extension utilizes a dynamically created cryptographically random key called 'code verifier'. A unique code verifier is created for every authorization request and its transformed value, called 'code challenge', is sent to the authorization server to obtain the authorization code. NEW To mitigate this attack, this extension utilizes a dynamically created cryptographically random key called 'code verifier'. A unique code verifier is created for every authorization request and its transformed value, called 'code challenge', is sent to the authorization server to obtain the authorization code. This transmission is sent through a secure API, and cannot be intercepted. END I know it repeats what was said in the explanation above, but it's an important enough point to merit repetition. I suggest changing Section 4.4.1 like this (because of a misuse of "MAY" that I missed before): OLD If the client is capable of using "S256", it MUST use "S256", as "S256" is Mandatory To Implement (MTI) on the server. Clients MAY use "plain" only if they cannot support "S256" for some technical reason and knows that the server supports "plain". NEW If the client is capable of using "S256", it MUST use "S256", as "S256" is Mandatory To Implement (MTI) on the server. Clients are permitted to use "plain" only if they cannot support "S256" for some technical reason and know that the server supports "plain". END Finally, I suggest changing this in Section 7.2: OLD "S256" method protects against eavesdroppers observing or intercepting the "code_challenge". If the "plain" method is used, there is a chance that it will be observed by the attacker on the device. The use of "S256" protects against it. NEW The "S256" method protects against eavesdroppers observing or intercepting the "code_challenge", because the challenge cannot be used without the verifier. With the "plain" method, the challenge can be directly used during the verification step, so "plain" does not protect against interception of the initial request. Because of this, "plain" SHOULD NOT be used, and exists only for compatibility with deployed implementations where the request path is already protected. The "plain" method MUST NOT be used in new implementations. END With that set of changes, or something like them (feel free to re-write, and certainly correct anything I got wrong!), I will clear this DISCUSS and we can move ahead. If you find anything fundamentally messed up in any of that, please do discuss it with me, and let's sort it out. And, again, thanks for the explanation that made this all clear. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Putting quotation marks around "code_verifier" and "code_challenge" in the formulas is confusing: it makes it look as if you're putting in those strings themselves, rather than the values of the variables.  It's probably unlikely that anyone would make that mistake, but I nevertheless suggest removing the quotation marks when you mean to refer to the values. -- Section 2 -- There is no real distinction between STRING and ASCII(STRING), because STRING is already defined to be ASCII. Using "ASCII(xxx)" only adds clutter, and a suggest removing it. So, for example, these last two comments would make changes such as this one: OLD BASE64URL-ENCODE(SHA256(ASCII("code_verifier" ))) == "code_challenge" NEW BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge END -- Section 4.3 -- I would very strongly prefer that S256 be the default, not "plain"... or that the method be required, with no default. I understand that this makes existing implementations break. -- Section 4.4 -- The word "code" is used for too many things, and "Authorization Code" is already the right name for what we're talking about here.  I suggest that in both the section title and body you use that term, to make it clear what you mean by the "code". Similarly, in Section 4.5 please say "code_verifier" rather than "secret". (Nat plans to make these changes.) -- Section 4.4.1 -- Please expand "PKCE", which is, at the moment, only expanded in the document title. (Nat plans to make a change for this.) -- Section 5 -- The SHOULD in the first paragraph is wrong.  You already have a MAY covering the general behavior.  You should just take out the "SHOULD", and just say that severs supporting backwards compatibility revert to the normal OAuth protocol. (Nat plans to make a change for this.) -- Section 6.2 -- I have the same comment here as in the other OAuth document: please shift the focus away from telling IANA how to handle tracking of the expert review, and make the mailing list something that the designated expert(s) keep track of. Also, please give more instructions to the DEs about what they should consider when they're evaluating a request (for example, should they approve all requests, or are there criteria they should apply?). For the first, here's a text change that I suggest we move toward for this sort of thing: OLD NEW Additional code_challenge_method types for use with the authorization endpoint are registered using the Specification Required policy [RFC5226], which includes review of the request by one or more Designated Experts. The DEs will ensure there is at least a two-week review of the request on the oauth-ext-review@ietf.org mailing list, and that any discussion on that list converges before they respond to the request. To allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that an acceptable specification will be published. Discussion on the oauth-ext-review@ietf.org mailing list should use an appropriate subject, such as "Request for PKCE code_challenge_method: example"). The Designated Expert(s) should consider the discussion on the mailing list, as well as <> when evaluating registration requests. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. END (Nat plans to make a change for this.) -- Section 7.2 -- For the first paragraph, after discussion with the author I suggest this: NEW Clients MUST NOT downgrade to "plain" after trying the S256 method. Because servers are required to support S256, an error when S256 is presented can only mean that the server does not support PKCE at all. Otherwise, such an error could be indicative of a MITM attacker trying a downgrade attack. END From nobody Thu Jun 11 12:02:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301591B2CC5; Thu, 11 Jun 2015 12:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 qlp2nfkqFxA3; Thu, 11 Jun 2015 12:02:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55CD81A92E0; Thu, 11 Jun 2015 12:02:16 -0700 (PDT) Received: from [192.168.10.236] ([12.217.69.145]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MLelb-1Z3Oac2swl-000qCR; Thu, 11 Jun 2015 21:02:14 +0200 Message-ID: <5579DB31.30807@gmx.net> Date: Thu, 11 Jun 2015 21:02:09 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150611184955.1618.38149.idtracker@ietfa.amsl.com> In-Reply-To: <20150611184955.1618.38149.idtracker@ietfa.amsl.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6lgMwev9DpRlpuxlk78KL3IffbuoEHirT" X-Provags-ID: V03:K0:+cIY2HC75Jz1cN9yuzd9XG8IN7N+VdGsjOgo73f6clK3Ri0CrqS cPZZQUu4R4jxGMG4nsECwxbU1JT8m/sYNmzqWQpM7ZZ11ipoEHulwSUFoeu2hsaM3O+cjMC XGx2dpO8UiWNwYBvXJwD/DULRLSfIdhBihRBH9puH5yAIVhFsC1aj9A8gPKNE8Ah4XGt6aI SsgpA5/2alV/80OrXGLFg== X-UI-Out-Filterresults: notjunk:1;V01:K0:QPZOrztC67Q=:CIxqh01ixSM+FKd43VNEvg zBIQfK2MX9lpLflQzpQtOIQ070dkTyHN7p8GogTP0oaCewVfWNNjREytLF8OApj66w8Z3yi+U pWIReZ6qCK4bcqU/Z0nkBV0VETCd9tdC7QTeR7tnax3ozyiB8maUxZw3pdDrNPnB3U7i+wNFf xOQVd/zpPj4wDv83AiB9p41irTcSjBdDSy0s24r/P7bGPh62bM0Jpg3OWTtwEAfy08mtKaUXx 5xLA+ik0pFxpIH9ZQhYtPSbzCJIOrPQ0ZctgE3sy9QsSTKuShFHoHl+W8wgRCjeZ99wP47m1m fuGKu9JK5HHM6E4aN/ILx1Ix0SwMVuxmtbtynQfGl0IRMR6rBWwNnnbOW9u1C7zs2K5uTvE6k qfxoym+97rv9qb5C35wbA3AHo3gaLozmluLUQcKFBUxjewF77IsBFCznlVCawbPdSqRUi4jXA zU2LyXpLz3fk+EDu9Ikoa460pG6WPXzG75yplKj1hKtcs4FlChMiphSetNKmiYko0xkXpylFx gmFsXJrXexhtMBIUg/qMA0cZa0yAtNonF8pNm0xGVEy3BtYuVhCgDKFM0SrD5gGsg7dl7BYoz QXcuiGAOWrIynRD/nn3OwMjElNnP8FvEo3ONvUwfRgZIbtVLHCDT3G/A/BUgZKTcxvFbn5per z9tqbtNK4J4/rb6yzCrwUds4kyo24gamEMKgCPrnqqUU9jA== Archived-At: Cc: draft-ietf-oauth-spop.ad@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, oauth@ietf.org, draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 19:02:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6lgMwev9DpRlpuxlk78KL3IffbuoEHirT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Barry, let me explain this pre-condition a bit more since I wrote the text: On 06/11/2015 08:49 PM, Barry Leiba wrote: > *** IMPORTANT *** I am still puzzled by this, in pre-condition (4), whi= ch > seems to contradict what John said and what I proposed above: >=20 > 4) The attacker (via the installed app) is able to observe responses= > from the authorization endpoint. As a more sophisticated attack > scenario the attacker is also able to observe requests (in > addition to responses) to the authorization endpoint. With the attack that occurred in the wild the main issue was that an attacker exploits the feature of smart phone OSs to register multiple apps using the same custom URI scheme. In this model the adversary will see response messages. However, it is possible for an attacker to also compromise the smart phone OS in such a way that he/she is also able to see the request as well as the responses. In such a "more sophisticated attack" the proposed mechanism does not help. Does this additional description help? Ciao Hannes --6lgMwev9DpRlpuxlk78KL3IffbuoEHirT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVedsxAAoJEGhJURNOOiAt4v4H/1eZLmkkTO59I0i0JAONcWat X2kWvYw8gL5OIBGJ5IX1PpEhSVLxwSVsbXQ9JTcq9elDF8gjxSlyTBkQeCicdfNh NqPmBu2yGKtsHmgWnf5Ny95nstOzw8kXiZGp8CbFK9QSimRCffJ5yh3u0lJM5lIj FZ1Bk/HCBOd3JVr7wiIQavIN7mwhH7WU1bJCPrLR0PJVOkT/WOp9uK1ueVR5mEDQ SxiXo89xPAu1oeNiUSDPvpao96GrwmWbTqjvka0lGWD1RpMjheN7zWcpYShr9mdi dExZauI2GJPa3ma0+4anr+yOa6cq7fWnc5SX8CS4axB1J9nUdRuHSh9NUsZMgEU= =MIes -----END PGP SIGNATURE----- --6lgMwev9DpRlpuxlk78KL3IffbuoEHirT-- From nobody Thu Jun 11 12:10:04 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068081B2CC0; Thu, 11 Jun 2015 12:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 XN2qAayWA0wJ; Thu, 11 Jun 2015 12:10:02 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 757DF1B2CFC; Thu, 11 Jun 2015 12:09:37 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so59902078igb.1; Thu, 11 Jun 2015 12:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dRa1G2+HDoLDcx06ivsGpUIXLdUS2oWoUbm63JtD9BA=; b=H14HAvey9+ik2AOgANxNqTQnu0urMUDmMi8vHwQefaRun7wnXz1M242Nxpr73j0Fxl 7zRNGel5TU3q7JTd0xlthh2jO3v1RBKcgXGTX4qo6HeZ4ob7GWkO5st2obgltlHKhouO plCePrunq4ck+ba7Jd7cJGlhG29TpxGtmXPuzDVPplZ/9+afVDVvHpooyuPMexsX5jug U3DpvBZJSV7CnwugYmirFGEjrQEr3VC0Q8FCkxmhLsOxr+1kBOTtY9buHh3rXifMLZri 942YoCj2354Vl2aECU5JyuTIIhCBMcyGD6+dCRMpG+6ovqLR6GQiCfna0bJMxA7m5GAc zHrw== MIME-Version: 1.0 X-Received: by 10.50.43.227 with SMTP id z3mr14893114igl.12.1434049776699; Thu, 11 Jun 2015 12:09:36 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.16.222 with HTTP; Thu, 11 Jun 2015 12:09:36 -0700 (PDT) In-Reply-To: <5579DB31.30807@gmx.net> References: <20150611184955.1618.38149.idtracker@ietfa.amsl.com> <5579DB31.30807@gmx.net> Date: Thu, 11 Jun 2015 20:09:36 +0100 X-Google-Sender-Auth: A6NvfKxlEuue7zCGWzKsj0zhKGk Message-ID: From: Barry Leiba To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth WG , draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth-chairs@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 19:10:03 -0000 Hi, Hannes, and thanks for clearing this bit up. >> 4) The attacker (via the installed app) is able to observe responses >> from the authorization endpoint. As a more sophisticated attack >> scenario the attacker is also able to observe requests (in >> addition to responses) to the authorization endpoint. .. > In this model the adversary will see response messages. However, it is > possible for an attacker to also compromise the smart phone OS in such a > way that he/she is also able to see the request as well as the > responses. In such a "more sophisticated attack" the proposed mechanism > does not help. Ah, got it. Then it would be good for (4) to say that, maybe just by adding to the end, "This mechanism does not protect again the more sophisticated attack." Sound OK? Barry From nobody Thu Jun 11 12:10:22 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4301B2D16; Thu, 11 Jun 2015 12:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 iK1Xbfpodveb; Thu, 11 Jun 2015 12:10:19 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 A5C421B2D08; Thu, 11 Jun 2015 12:10:19 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so59911878igb.1; Thu, 11 Jun 2015 12:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lzvkcE/paqSvD6JdlFK2Qq9njuNTYjzEj/1Yo6z0vok=; b=D97+pwa5zqMZ2UN+sog2b518HbdjldfhAXCoxn0xQAllfFTPeN277/FWs7VK4vz2c5 cUX0ubV1VAj4+BM3F/DzgxL9qP3WNHYoAglqgkZQC6m37Aei08ehrIbnyE5Wb7DGFahR snQtnP/1o50B1WW1v3leXvmeem7Mn53iS3kPr9ZiWGasNAOxm53H7Z0SxRGzHlxJa1EN 1vk4Jwyc59rqE2k7su4KGhL/qEu9teYjVF9MUApDK4IYkkDqQ6107JPbdAY6VDbeVjDp QCybIYBxH+svEKQ9o3UEr2LYByCy3RC0ZFNdrnkMdDv7MsU1sBWWBlynYV31C0QmGDqL g7Ew== MIME-Version: 1.0 X-Received: by 10.50.7.68 with SMTP id h4mr15095142iga.40.1434049818328; Thu, 11 Jun 2015 12:10:18 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.16.222 with HTTP; Thu, 11 Jun 2015 12:10:18 -0700 (PDT) In-Reply-To: References: <20150611184955.1618.38149.idtracker@ietfa.amsl.com> <5579DB31.30807@gmx.net> Date: Thu, 11 Jun 2015 20:10:18 +0100 X-Google-Sender-Auth: hzpDUKAVcUq61uhLXgGm6FKbij4 Message-ID: From: Barry Leiba To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth WG , draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth-chairs@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 19:10:20 -0000 > Hi, Hannes, and thanks for clearing this bit up. > >>> 4) The attacker (via the installed app) is able to observe responses >>> from the authorization endpoint. As a more sophisticated attack >>> scenario the attacker is also able to observe requests (in >>> addition to responses) to the authorization endpoint. > .. >> In this model the adversary will see response messages. However, it is >> possible for an attacker to also compromise the smart phone OS in such a >> way that he/she is also able to see the request as well as the >> responses. In such a "more sophisticated attack" the proposed mechanism >> does not help. > > Ah, got it. Then it would be good for (4) to say that, maybe just by > adding to the end, "This mechanism does not protect again the more > sophisticated attack." Sound OK? That should be "against", of course, not "again". I hate tupos. Barry From nobody Thu Jun 11 13:05:10 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE911B311B; Thu, 11 Jun 2015 13:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 p6KqHhsL4nKw; Thu, 11 Jun 2015 13:05:07 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347F31B30A0; Thu, 11 Jun 2015 13:05:06 -0700 (PDT) X-AuditID: 12074423-f79496d000000d43-a7-5579e9f1ff1c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id DB.5B.03395.1F9E9755; Thu, 11 Jun 2015 16:05:05 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t5BK54Y8015991; Thu, 11 Jun 2015 16:05:04 -0400 Received: from [192.168.2.154] ([12.217.69.145]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5BK50PI014281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2015 16:05:02 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: Date: Thu, 11 Jun 2015 13:04:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixG6nrvvxZWWowa3VxhaHFl9itTi76Ta7 xYrl5RYvFu9ktpjxZyKzxe25K9ksTr59xebA7tGyqpfZY8mSn0wBTFFcNimpOZllqUX6dglc GS1NHUwFL0QrLryYxtLA2CHYxcjJISFgInH62TdGCFtM4sK99WxdjFwcQgKLmSS+35vLBOFs ZJSYdeY6O4Szlkni78T/YC3MAuoSf+ZdYgaxeQX0JB49fcwOYgsLpEscf/iWDcRmE1CVmL6m hQnE5hQIlOjc/5kVxGYBiq/Z/BpsHbPAL0aJ5p1fmSCGakssW/gaaqiVxL62qVBnbGGU+Lnz BNhUEQFNieefpwAlOIAOl5X4ulVuAqPgLCQ3zUJy0ywkYxcwMq9ilE3JrdLNTczMKU5N1i1O TszLSy3SNdPLzSzRS00p3cQIDnoX5R2Mfw4qHWIU4GBU4uGtOFERKsSaWFZcmXuIUZKDSUmU d/+NylAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzbrwLleFMSK6tSi/JhUtIcLErivJt+8IUI CaQnlqRmp6YWpBbBZGU4OJQkePOB0S0kWJSanlqRlplTgpBm4uAEGc4DNDwEpIa3uCAxtzgz HSJ/ilFRSpz35wughABIIqM0D64XlpReMYoDvSLMuwykigeY0OC6XwENZgIavJC5HGRwSSJC SqqBsSKSp3qPwU8/dctdNZ9nmd1nnKwmf0xW3DFYyVbareeC5lF/kUWnv7pvcxVhVG0/vFQ1 65OmwiH9rfsuTGnyYuznCdT62ROr1mbhFm/SM7l2/cYT10SVJlxK0Bf/+etkflnX/9niqskV io1aZ3bXmtqtWeOovy1CbGPc0qNG/5bJzbacs3yxEktxRqKhFnNRcSIAsFtdNiUDAAA= Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "" Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 20:05:09 -0000 > On Jun 9, 2015, at 9:57 AM, Barry Leiba = wrote: >=20 > Hi, Justin. Thanks for the response and discussion. >=20 >>> -- Section 2 -- >>>=20 >>> The introspection endpoint MUST be protected by a transport-layer >>> security mechanism as described in Section 4. >>>=20 >>> I know what it means for a communication path to be protected by = TLS, but >>> I don't know what it means for an endpoint to be. Can you explain = that? >>=20 >> The gist is simple: It must be served over HTTPS, not HTTP. >=20 > Right; that's protecting the communication path. So I suggest this > (and it's a minor point; I'm OK with no further discussion, whether > you agree with the change or not): >=20 > NEW > The introspection communication path MUST be protected by a > transport-layer security mechanism as described in Section 4. > END >=20 >>> -- Section 2.1 -- >>> The server MUST support POST, and MAY support GET. What's the value = in >>> that? I don't see any way for a client (I mean HTTP client, not = Oauth >>> client, here) to know, so all clients will have to send POST to be = sure >>> it will work. Are you really expecting to have clients that want to = ask >>> this, but that can't send POST? Given that you call out privacy = concerns >>> with GET, I don't see why it's there at all. >>=20 >> GET is a deployment optimization that some servers will offer, and = the >> OAuth client will tell the HTTP client which verb to use. The OAuth = client >> might know through configuration (assuming a tighter coupling than >> defined by the interoperable protocol) >=20 > Two things: >=20 > 1. Why is GET an optimization? It has privacy disadvantages, and I > don't see any advantages. >=20 > 2. This "tight coupling" thing is something that I think weakens the > interoperability of the OAuth protocol in general, and I've never > liked it. In this case, in particular, I don't see any advantage to > it, and I don't understand why it's useful to have an option that only > works if you have inside knowledge, for no benefit. >=20 > Why is it ever good to have clients that only work with certain > servers, when it's just as easy to make sure that all clients work > with all servers? >=20 > Barry I can see your point here, and others have raised it as well. Part of = the reason the GET option is there is that most (if not all) of the = existing implementations of this protocol enable it anyway. Having = thought about this a bit, I would be fine with simply saying that POST = is required and remaining silent on other methods in the main section. = We can keep the warnings against also allowing GET in the security = considerations. Will that work? =E2=80=94 Justin From nobody Thu Jun 11 13:06:20 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1E31B311E; Thu, 11 Jun 2015 13:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GvYdQAb1Zrao; Thu, 11 Jun 2015 13:06:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7201B311C; Thu, 11 Jun 2015 13:06:16 -0700 (PDT) Received: from [192.168.10.236] ([12.217.69.145]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M9eHT-1YtTYZ25k7-00CygM; Thu, 11 Jun 2015 22:06:13 +0200 Message-ID: <5579EA2F.5020404@gmx.net> Date: Thu, 11 Jun 2015 22:06:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba References: <20150611184955.1618.38149.idtracker@ietfa.amsl.com> <5579DB31.30807@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sBUu5T65HPnKXQGI3rHUTLuuEHr1Nk698" X-Provags-ID: V03:K0:t6xbDGfYZwR3FmTXtTKcYh7P7HSsi833Z77VsbhqgCaAdTI+Y9P PjZFEHUnULsB07Tq37f+7/k0+7ZCCW8UuORhYBQqcgJWsuRSPSDeSoITCZ1D582SidHn/eB Q6UKgJg1grxr2Y4Uu0ztTq+eIg2OBGhqnT7rYwe8lWy/TGenQjQR6vwCXBSsBKnWiESNm56 oX9ePF//Gu+DzG1eCMo9w== X-UI-Out-Filterresults: notjunk:1;V01:K0:AdX+XYNQIT0=:hLxi3tbz9ZPM1XLY2nAVkU Dif+zi4MhCUAnwRhL3l2Pz9ehdn+kYDhYYZYnkjwo9gjHGln0niJua5vTd9dlTNZYYgnkeR73 H9CvmFLghj2df7/7pANaJtf+nGLNep+EnM2dc8/B03u8/nQbEUsfUBmLb3dpVP/RIztYZNGss keoVhZESFLIUTfYI55cGHABCaVka6or960NR4znJuwX2KAiEDkyRjk7zlKF9tTQM086bNmc7T 1gYk9jk8BYB+h+RzPPBVXVFyqpQSDBZrUBHny/HDVoNcE5V8u3H2cH8m4yg/x5++1khwiVAF1 WqS7T8Me7B4rbrWzgMicbFN0e6yUfSr1G+nK50tuT+Afm7Hd/48SemENYatcBr32gLP3uL2RB zb/c/n972Jv5VGzIyCFZ2BFeOpXoS71cV0PjeSeWecEPGMhTKNwg/mMLeSaiTOV2GMlxPR8MO vCbxz3YrrTIIOiXqb+EDF9b2zGORc7h88GHrkRscCU5JoBdoT3ij+1JQHNWtgJ7v4/yLEqBBO uf9/DohgmkaBf8CgHfgK4HjUYkgWyjaswV+TxX27YV/ibJFRrJEN6C6zQR2JUq6/fZku2/qaH ibZzXNo7wm81Fz1PJAcOed3PaiFBS1fd9FknBJI5nP4w4tXyJDfBIf/x6Rp+faCeKFhrQ5InJ FU7T4+AG2pChLQWUj7mtlb+ZWKku4gUvzn5xky8U+Y0lrfg== Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth WG , draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , oauth-chairs@ietf.org, draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 20:06:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sBUu5T65HPnKXQGI3rHUTLuuEHr1Nk698 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sounds good to me, Barry! On 06/11/2015 09:10 PM, Barry Leiba wrote: >> Ah, got it. Then it would be good for (4) to say that, maybe just by >> > adding to the end, "This mechanism does not protect again the more >> > sophisticated attack." Sound OK? > That should be "against", of course, not "again". I hate tupos. --sBUu5T65HPnKXQGI3rHUTLuuEHr1Nk698 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVeeovAAoJEGhJURNOOiAtXMQIAJa+3VSaixfSNv4Fkk8hTSeH P6vw3BHcfe1rdyAWZc107js7PLlb4iJI5TG9P4TVmTzJ17kABwThAkMecBfY2JKP iLOO0l57OcAHK8JnAkAcse7TUy1DT9Jpk1avLM2wANAkRjspq3Q6vv+eMNLtc3Jo cwcOIe03LxTdq7y2ZI2t5z+LJgtIZjdFPPUmKQ7qzgvkIw0gLYI63+ITJFJmQHMo 6XFuzAgSe1ryh5jNl5Vv3N5F2uVAJnOTCUB9WNAAFO7bjRBTvjS5xHU0EUVe9Afc mLzFwVNb6cpLByE+PvN/q5ArLtfGfo8SfVQWJ44GIu77w/OVT6+Z89oFhxkQAFM= =FaeO -----END PGP SIGNATURE----- --sBUu5T65HPnKXQGI3rHUTLuuEHr1Nk698-- From nobody Thu Jun 11 14:01:15 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E8B1B30DD; Thu, 11 Jun 2015 14:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bx659_d1IeLn; Thu, 11 Jun 2015 14:01:02 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C151B317B; Thu, 11 Jun 2015 14:01:00 -0700 (PDT) X-AuditID: 1209190e-f79b96d000000e0e-45-5579f70b5d22 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 88.56.03598.B07F9755; Thu, 11 Jun 2015 17:00:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t5BL0wOo026045; Thu, 11 Jun 2015 17:00:58 -0400 Received: from [192.168.2.154] ([12.217.69.145]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5BL0sGg018532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2015 17:00:56 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 14:00:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixG6nrsv9vTLUYEqTnMX0M38ZLc5uus1u sWJ5ucWLxTuZLWb8mchscXvuSjaLk29fsTmwe3x58pLJY8mSn0wBTFFcNimpOZllqUX6dglc Ge9nn2MvaNKv+Hubv4GxQ62LkZNDQsBE4v7MWYwQtpjEhXvr2boYuTiEBBYzSXz89J8ZwtnI KLF6Sg+Us5ZJYvb0jUwgLcwC6hJ/5l1iBrF5BfQkHj19zA5iCwsUSEw+18EGYrMJqErMX3kL rJ5TwEmifcoVsHoWoPismz9ZQIYyC/xilHhyZCc7xFBtiWULX0MNtZLY/ngG2CAhAUeJRe2z WUBsEaDmq8d+AMU5gO6Wlfi6VW4Co+AsJCfNQnLSLCRTFzAyr2KUTcmt0s1NzMwpTk3WLU5O zMtLLdI11svNLNFLTSndxAgKeE5Jvh2MXw8qHWIU4GBU4uGtOFERKsSaWFZcmXuIUZKDSUmU d/WXylAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzbrwLleFMSK6tSi/JhUtIcLErivJt+8IUI CaQnlqRmp6YWpBbBZGU4OJQkeO2+AjUKFqWmp1akZeaUIKSZODhBhvMADfcDqeEtLkjMLc5M h8ifYlSUEuctAEkIgCQySvPgemEJ6RWjONArwrynQap4gMkMrvsV0GAmoMELmctBBpckIqSk Ghj9VpbmMBnGHN+1pbmnQmj1pQu7Vszctk08dmL3Ck+TP2pu9958Wql1VzRj9msr+ZaOwqMS 4tM3HJ8cqHDkBNNHcxvtN/9qEnISz2ZwSPJGbj4TerbFw8b09HPFu18Mnc6x7r869dxnu6Ue PenWk4/FZ5p96T9kdWz7T4+pVoc+XZ6tUXr1iVOPEktxRqKhFnNRcSIAdajAOiMDAAA= Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 21:01:09 -0000 Hi Alissa, thanks for your review. Responses are inline. > On Jun 8, 2015, at 9:40 AM, Alissa Cooper wrote: >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-oauth-introspection-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > =3D Section 2.1 =3D > "The endpoint MAY allow other parameters to provide further context to > the query. For instance, an authorization service may need to know > the IP address of the client accessing the protected resource in > order to determine the appropriateness of the token being = presented." >=20 > How does the protected resource know whether it needs to include such > additional parameters or not? > What is meant by the "appropriateness" of > the token?=20 >=20 > In general if we're talking about a piece of data that could be = sensitive > like client IP address, it would be better for there to be specific > guidelines to direct protected resources as to when this information > needs to be sent. I note that Section 5 basically says such > considerations are out of scope, but if this specific example is to be > provided here then they seem in scope to me. We are trying to leave the door open to extensions and adaptations of = this protocol, specifically around the protected resource passing along = information about the client=E2=80=99s request. The AS might be able to = help the RS detect funny business on the client=E2=80=99s behalf (i.e., = whether it=E2=80=99s appropriate for the client to presenting the token = in this context) if it has that information.=20 The example isn=E2=80=99t supposed to be normative or pull extra = considerations into scope of this protocol but instead to point out = where it could go. Do you have a suggestion for rewording this? Perhaps it would be best to = move all of this language to the security considerations section, as = it=E2=80=99s more guidance for what extensions to this spec would need = to think about as opposed to what pure implementations of this spec = would need. >=20 > =3D Section 5 =3D > "One way to limit disclosure is to require > authorization to call the introspection endpoint and to limit calls > to only registered and trusted protected resource servers." >=20 > I thought Section 2.1 made authorization to call the introspection > endpoint mandatory. This makes it sound like it's optional. Which is = it? Thanks for this catch. Authorization used to be optional, and it looks = like we missed updating this text. I=E2=80=99ll fix that in the next = revision. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > =3D Section 1.1 =3D > There is no reference to RFC2119 here, which may be okay but most > documents include it if they use normative language (I think). >=20 Not sure how that happened, this should have been included by the = xml2rfc tooling, I=E2=80=99ll look into it. > =3D Section 2 =3D > "The > definition of an active token is up to the authorization server, but > this is commonly a token that has been issued by this authorization > server, is not expired, has not been revoked, and is within the > purview of the protected resource making the introspection call." >=20 > Is "within the purview" a term of art for OAuth 2.0? Is there a more > specific way to describe what is meant here? Also, I note that in the > description of the "active" member in Section 2.2, this criterion is = not > listed. It seems like these should be aligned. It is not a term of art in OAuth, and I can change that to =E2=80=9Cis = able to be used at the protected resource=E2=80=9D if that=E2=80=99s = clearer. I will also add that to the list of checks about the active = value, thanks. >=20 > =3D Section 2.2 =3D > "Note that in order to avoid disclosing too much of the > authorization server's state to a third party, the authorization > server SHOULD NOT include any additional information about an > inactive token, including why the token is inactive." >=20 > Seems like this should be a MUST NOT unless there's some reason for > providing anything other than active set to false. Same comment = applies > in Section 4. That=E2=80=99s why it=E2=80=99s SHOULD =E2=80=94 which translates, = roughly, to =E2=80=9Cdo it this way unless you=E2=80=99ve got a really, = really good reason not to=E2=80=9D. >=20 > =3D Section 2.3 =3D > It seems like there is another error condition and I'm wondering if = its > handling needs to be specified. Per my question in Section 2.1, if = it's > possible that the request is properly formed but is missing some > additional information that the authorization server needs to evaluate > it, should there be an error condition specified for that case? >=20 Not by this specification, since there isn=E2=80=99t a mechanism for the = protected resource to figure out automatically what to do next. If = there=E2=80=99s a future extension specifying this extra information, it = can define its own value. =E2=80=94 Justin >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jun 11 14:08:25 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C809A1B3196; Thu, 11 Jun 2015 14:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mkekspqV4I5D; Thu, 11 Jun 2015 14:08:18 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C757D1B3192; Thu, 11 Jun 2015 14:08:17 -0700 (PDT) X-AuditID: 12074424-f79b06d000000cfd-cb-5579f8bf66d9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 3C.C8.03325.FB8F9755; Thu, 11 Jun 2015 17:08:15 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t5BL8Ekh022273; Thu, 11 Jun 2015 17:08:15 -0400 Received: from [192.168.2.154] ([12.217.69.145]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5BL8As7022762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2015 17:08:12 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: <20150610141244.19755.30964.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 14:08:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150610141244.19755.30964.idtracker@ietfa.amsl.com> To: Brian Haberman X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6norv/R2WoQcd2a4uZPf8YLc5uus1u sWJ5ucWLxTuZLZbuvMdqMePPRGaL23NXslmcfPuKzYHDY/Gm/WweS5b8ZPKYefwLSwBzFJdN SmpOZllqkb5dAlfG87MzWArOc1Y82TObpYGxg6OLkZNDQsBE4t2bJWwQtpjEhXvrgWwuDiGB xUwSh5qeQzkbGSUOvWyHctYySVz5eIYFpIVZQF3iz7xLzCA2r4CexKOnj9lBbGGBeIm7fW1g cTYBVYnpa1qYQGxOASeJrsm3wHpZgOKfn95iBhnKLLCJSWLZwZ2MEEO1JZYtfA011ApowXWw BiEBR4m3q2eB2SICuhKNHSuAbA6gu2Ulvm6Vm8AoOAvJSbOQnDQLydQFjMyrGGVTcqt0cxMz c4pTk3WLkxPz8lKLdM31cjNL9FJTSjcxguPARWUHY/MhpUOMAhyMSjy8FScqQoVYE8uKK3MP MUpyMCmJ8q7+UhkqxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3+1WgHG9KYmVValE+TEqag0VJ nHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBO/bb0CNgkWp6akVaZk5JQhpJg5OkOE8QMN/gtTw Fhck5hZnpkPkTzEqSonzCn8HSgiAJDJK8+B6YWnqFaM40CvCvBYgVTzAFAfX/QpoMBPQ4IXM 5SCDSxIRUlINjBNfMd5fHps63TCIrVhKf91M5qkO7N1f7uybMtV5y8M7Rc9q9a89EvSe9mN1 QOPMfcfW84tUtnPn8d0IOjHtpJLC3S8fA9PWTDnDcjh6Jpv5vFyzLuu7fs0eD4K+bmtbL8Ul cDJj1fcLIfN9KqY9Zr5c9GD5k1azCakP5u09tX7n/yYr9r2z1q5SYinOSDTUYi4qTgQASFi7 IC4DAAA= Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, "" , draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , oauth-chairs@ietf.org Subject: Re: [OAUTH-WG] Brian Haberman's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 21:08:20 -0000 Brian, thanks for your review. This is supposed to be the =E2=80=9Cauthorization server=E2=80=9D = (that=E2=80=99s a typo), which is where the introspection endpoint is = almost always hosted. =E2=80=94 Justin > On Jun 10, 2015, at 7:12 AM, Brian Haberman = wrote: >=20 > Brian Haberman has entered the following ballot position for > draft-ietf-oauth-introspection-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > * In Section 2.1... is the authorization service and the introspection > endpoint the same device? >=20 >=20 From nobody Thu Jun 11 14:32:42 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C010D1B2BA7; Thu, 11 Jun 2015 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 upjPg7GrQvnZ; Thu, 11 Jun 2015 14:32:39 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 C53A21B2B27; Thu, 11 Jun 2015 14:32:39 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so12903670ieb.0; Thu, 11 Jun 2015 14:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Zlxk4F6A0WyEghlDmZrVF9tQeJE2/AIKMrlXobKnxWU=; b=spELvlozf2hI+tb2mZpAJ7QSm8VjFPNLUvayVY7TPF6nyPpttb5GKazgp1fdjG+DZW s1d0XX1/jNZzOzck5HgvJmyj1YPxBqmS9cGM348n0oRjIe5HDLDy8hstoFAOwTWqdDee h+Of63PF4mAdiWMQas0Xnx3HfJS9hRjOVshObrIWw4BDBku8KqYBHyg45/eOKepFl5Cq bboTUMsCIUBN8OjGjdLee4S5//BSOHznad1T73B0rJQOTLke5kjopQ2uKEblIKADxa+U inkxpXDhC2+Q61zv3egYj/ZK436FzUMu+2eZn2PfARxcav/1DrGLaRdE4676drcA4GdX 0OPw== MIME-Version: 1.0 X-Received: by 10.107.137.42 with SMTP id l42mr13782917iod.60.1434058359325; Thu, 11 Jun 2015 14:32:39 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.16.222 with HTTP; Thu, 11 Jun 2015 14:32:39 -0700 (PDT) In-Reply-To: References: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 22:32:39 +0100 X-Google-Sender-Auth: K1oxDTNuqmKA_mztqT0psdpSRgE Message-ID: From: Barry Leiba To: Justin Richer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "" Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 21:32:40 -0000 >> 1. Why is GET an optimization? It has privacy disadvantages, and I >> don't see any advantages. >> >> 2. This "tight coupling" thing is something that I think weakens the >> interoperability of the OAuth protocol in general, and I've never >> liked it. In this case, in particular, I don't see any advantage to >> it, and I don't understand why it's useful to have an option that only >> works if you have inside knowledge, for no benefit. >> >> Why is it ever good to have clients that only work with certain >> servers, when it's just as easy to make sure that all clients work >> with all servers? > > I can see your point here, and others have raised it as well. Part of > the reason the GET option is there is that most (if not all) of the > existing implementations of this protocol enable it anyway. Having > thought about this a bit, I would be fine with simply saying that POST > is required and remaining silent on other methods in the main section. > We can keep the warnings against also allowing GET in the security > considerations. Will that work? That will be of great excellence all 'round. Thanks! Barry From nobody Thu Jun 11 14:54:11 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237B91B2C2F for ; Thu, 11 Jun 2015 14:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0qQ60NWKTAkk for ; Thu, 11 Jun 2015 14:54:08 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2781B31C1 for ; Thu, 11 Jun 2015 14:54:07 -0700 (PDT) X-AuditID: 12074424-f79b06d000000cfd-10-557a037e3912 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id AE.FA.03325.E730A755; Thu, 11 Jun 2015 17:54:07 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t5BLs6SG021093 for ; Thu, 11 Jun 2015 17:54:06 -0400 Received: from [192.168.2.154] ([12.217.69.145]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5BLs4oe016231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 11 Jun 2015 17:54:06 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_3194CC63-15E1-4C31-A946-07F8CCB2248D" Message-Id: <8EEEA252-29A1-443B-90BF-3B3A21F0619B@mit.edu> Date: Thu, 11 Jun 2015 14:54:02 -0700 To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrVvPXBVqsHMmk8XJt6/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMWXvdvaC1SoVzS3PmBsYu+S7GDk5JARMJI7e280KYYtJXLi3 nq2LkYtDSGAxk8TnyR9YIJxjjBKPni5ihnAOMUn8aF3LAtLCJqAqMX/lLSYQm1kgQeL+wpds ILawgKZE84GlYHFeASuJ7kt/mUFsFqD6h2t+gtkiAuoSa87/hKrRA1rwmL2LkQPoDFmJr1vl JjDyzkIydRaSKoi4tsSyha+ZIWxNif3dy1kwxTUkOr9NZF3AyLaKUTYlt0o3NzEzpzg1Wbc4 OTEvL7VI11wvN7NELzWldBMjKCjZXVR2MDYfUjrEKMDBqMTDW3GiIlSINbGsuDL3EKMkB5OS KO/qL5WhQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4DX8B5XhTEiurUovyYVLSHCxK4rybfvCF CAmkJ5akZqemFqQWwWRlODiUJHi1mapChQSLUtNTK9Iyc0oQ0kwcnCDDeYCG/2cEquEtLkjM Lc5Mh8ifYlSUEud9ApIQAElklObB9cKSxitGcaBXhHnPgVTxABMOXPcroMFMQIMXMpeDDC5J REhJNTBOeXuirzLKuJv1k//TwqNdQi22hS4Xrp84IG649jhjVse92btsevY3rj+0eW6L7+bq P07c295HaJ45MWne+hs8CUH6s565Nq55NpGTt31SmD6T2+Li5XK2IaGOi4P5JouZe1zN+TJx wrI+gWBTB20eK/HvaVLLrJb9yzH4NtvwEVtRTEO45hElluKMREMt5qLiRADWLK4b9QIAAA== Archived-At: Subject: [OAUTH-WG] Proposed change to Introspection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 21:54:10 -0000 --Apple-Mail=_3194CC63-15E1-4C31-A946-07F8CCB2248D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the IESG review, several reviewers have brought up an issue with = current normative language: The protected resource calls the introspection endpoint using an HTTP POST [RFC7231 ] request with = parameters sent as "application/x-www- form-urlencoded" data as defined in [W3C.REC-html5-20141028 = ]. The authorization server MAY allow an HTTP GET [RFC7231 = ] request with parameters passed in the query string as defined in [W3C.REC-html5-20141028 = ].=20 The contention is that by saying that the server MAY support GET in = addition to POST, no client can actually count on there being GET = capability.=20 My proposed fix was to remove the =E2=80=9CMAY allow GET=E2=80=9D = sentence above. The spec would require POST support and remain silent on = other methods. This would implicitly mean that you could implement GET = as well (and most implementations have), but it=E2=80=99s implicitly = outside the scope of the spec. We would keep the discussion of the GET = method in the security considerations, as some implementors might want = to disable GET for those reasons. Since this change doesn=E2=80=99t really effectively change the = deployment profile of the document, it=E2=80=99s my view that this = doesn=E2=80=99t need another WGLC if we adopt this change. If you can = think of a reason for us to *NOT* make this change, please post your = concerns and suggested fix to the list. Thanks, =E2=80=94 Justin= --Apple-Mail=_3194CC63-15E1-4C31-A946-07F8CCB2248D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In the IESG review, several reviewers have brought up an = issue with current normative language:

   The protected =
resource calls the introspection endpoint using an HTTP
   POST [RFC7231] request with parameters sent as =
"application/x-www-
   form-urlencoded" data as defined in [W3C.REC-html5-20141028].  The
   authorization server MAY allow an HTTP GET [RFC7231] request with
   parameters passed in the query string as defined in
   [W3C.REC-html5-20141028]. =
The contention is that by saying that the server = MAY support GET in addition to POST, no client can actually count on = there being GET capability. 

My proposed fix was to remove the = =E2=80=9CMAY allow GET=E2=80=9D sentence above. The spec would require = POST support and remain silent on other methods. This would implicitly = mean that you could implement GET as well (and most implementations = have), but it=E2=80=99s implicitly outside the scope of the spec. We = would keep the discussion of the GET method in the security = considerations, as some implementors might want to disable GET for those = reasons.

Since = this change doesn=E2=80=99t really effectively change the deployment = profile of the document, it=E2=80=99s my view that this doesn=E2=80=99t = need another WGLC if we adopt this change. If you can think of a reason = for us to *NOT* make this change, please post your concerns and = suggested fix to the list.

Thanks,
 =E2=80=94 = Justin
= --Apple-Mail=_3194CC63-15E1-4C31-A946-07F8CCB2248D-- From nobody Thu Jun 11 15:25:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5591B3380; Thu, 11 Jun 2015 15:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EzrEn1pRlF8B; Thu, 11 Jun 2015 15:25:49 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E0131B337F; Thu, 11 Jun 2015 15:25:49 -0700 (PDT) X-AuditID: 12074423-f79496d000000d43-cd-557a0aeba693 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 66.F3.03395.CEA0A755; Thu, 11 Jun 2015 18:25:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t5BMPkQd024789; Thu, 11 Jun 2015 18:25:47 -0400 Received: from [192.168.2.154] ([12.217.69.145]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5BMPgjZ029679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jun 2015 18:25:44 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: <20150610002416.13636.71337.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 15:25:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150610002416.13636.71337.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1n3DVRVqsPI5s8X8ztPsFmc33Wa3 WLG83OLF4p3MFjP+TGS2uD13JZvFybev2BzYPZYs+cnkMWvnE5YApigum5TUnMyy1CJ9uwSu jKata9gLHilWXNl2kK2BcZl0FyMHh4SAicSHx4ZdjJxAppjEhXvr2UBsIYHFTBJrt4p0MXIB 2RsZJab++sEC4axlkpj84TBYFbOAusSfeZeYQWxeAT2JR08fs4PYwgIZEh+evGICsdkEVCWm r2lhAlnGKeAk0bhBCiTMAhRe+f4xI8hMZoFfjBJPjuxkh5ipLbFs4WuomVYSG3sPMkJc5Cix bm8/WFxEQEniefNWFogHZCW+bpWbwCg4C8lFs5BcNAvJ1AWMzKsYZVNyq3RzEzNzilOTdYuT E/PyUot0zfRyM0v0UlNKNzGCgp3dRXkH45+DSocYBTgYlXh4K05UhAqxJpYVV+YeYpTkYFIS 5V39pTJUiC8pP6UyI7E4I76oNCe1+BCjBAezkgiv4S+gHG9KYmVValE+TEqag0VJnHfTD74Q IYH0xJLU7NTUgtQimKwMB4eSBO8yzqpQIcGi1PTUirTMnBKENBMHJ8hwHqDh7iA1vMUFibnF mekQ+VOMilLivNkgCQGQREZpHlwvLBm9YhQHekWYdxJIFQ8wkcF1vwIazAQ0eCFzOcjgkkSE lFQDI3t2TJQyy/V1J/n3a05u05tfmy3cK6Hxh7Vx1wL/tzMfc5y37eLm/brmffLjziWz1z03 yrL+kr8spfT5lX8Rr6yXXX42I0jUbwVjm/SXudw7H0rd7ImO6jyt23riT7uPbnLhjkoO4Tef /74/tsj51nemtxpn5baf4Sphf7/HRr7R67Ow/ER/OyWW4oxEQy3mouJEAGddh6YhAwAA Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "" Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 22:25:52 -0000 Ben, thanks for your review. Comments inline. > On Jun 9, 2015, at 5:24 PM, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-oauth-introspection-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I concur with Alissa's discuss. =20 >=20 > Additional comments: >=20 > -- There is no reference to RFC 2119, but there seems to be lots of > capitalized 2119 keywords. If those are intended to have the 2119 > meaning, please add the usual reference. (I assume that these are > intended as 2119 keywords for the remainder of the review.) >=20 This seems to be a bug in the xml2rfc template, I=E2=80=99ll fix that.=20= > -- 2.1, first paragraph: >=20 > If the server MAY support GET, how does a client know to use it? Would > you expect them to try and fail? Was brought on by Barry Lieba, my suggested fix is to say server MUST = support POST, and remain silent on other verbs. Will that suffice? >=20 > -- 3 >=20 > Is there a reason not to use a more standard IANA procedure? (I.e. let > people request registrations to IANA, and have them forward the = requests > to the DE?) >=20 > --3.1, under "Name" >=20 > The MUST seems unnecessary, as that's the whole point of a registry. I pulled the IANA language from other specs, I=E2=80=99ll defer the = proper wording and structure of this to other experts. >=20 > -- 4: > The security considerations have a lot of restated 2119 keywords. If = you > want to reinforce those here, it would be better to do so with > descriptive language, rather than having multiple occurrences of the = same > normative language. Redundant normative language is error prone, > especially for future updates. Noted. We=E2=80=99re not trying to re-state normative requirements in = multiple locations, so I=E2=80=99ll carefully read through this again to = make sure we=E2=80=99re saying something new where we add another 2119 = statement. >=20 > -- 4, bullet list: >=20 >=20 > It seems odd to have 2119 keywords in a "For instance" section. This was at the request of WG members and I=E2=80=99m open to wording it = better. People wanted the protected resources to be able to count on = count on the AS doing at least some reasonable checks on the token=E2=80=99= s state. We can't prescribe exact AS behavior because the nature of = tokens is going to vary so wildly (some expire, some don=E2=80=99t). = What we want to do is provide a set of common checks that servers need = to do in the right circumstances, depending on the nature of their = tokens.=20 >=20 > --4, 6th paragraph from end >=20 > The reference to [TLS.BCP] should probably be normative. It=E2=80=99s a best current practice on deployment practice of a = supporting protocol, I think informative is the right level here but = I=E2=80=99ll defer to other expertise if there=E2=80=99s a better form. >=20 > -- 4, last two paragraphs:=20 >=20 > "An authorization server offering token introspection MUST be able to > understand the token values being presented to it during this call." = and > "the authorization server MUST be able to decrypt and validate the = token > in order to access this information." >=20 > These seem more like statements of fact than normative language. This is a fair characterization of this section, we can change those to = =E2=80=9Cneeds to=E2=80=9D or lowercase =E2=80=9Cmust=E2=80=9D. =E2=80=94 Justin >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jun 18 07:06:07 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B571B31DD for ; Thu, 18 Jun 2015 07:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 CpuZ5tmJUr9M for ; Thu, 18 Jun 2015 07:06:04 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 AC92B1B31B2 for ; Thu, 18 Jun 2015 07:06:04 -0700 (PDT) Received: by obbsn1 with SMTP id sn1so54672396obb.1 for ; Thu, 18 Jun 2015 07:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Mm0BsU65YKJExQcjGh3UzmwS8MFCTpx7fLUsnE87xDs=; b=JAlp8Vawm1TxEgq1PghLdFH9EySoLYm2EUWA4Fkikpuj2b2u6T4xcl7Fc/hfOUA7vP /xxseY+Dgnb+nauz7c5rr3DyJWf9TzpJwhQIekROqY1lxCTACVjeoYcD40VgIa/aE2Lm wa+mie7MYAMtfO1TfkLpAaNhbLvBDjEDb3WO1weys/ub6/u5kUz92+4oLCjaHGwTfwp0 2HwTWfJ15B2BRQVtlxeDw0r6z6UyTYzBEfSZhVX9DBkHT+Gy+qzfP0XRyA1skYfHoF3V LBHqTWQsqXZoMI4aW7rWNGchBAk9Mlc9hhWXhR91NcnZ0qorUmmymjRdmk/EtQhbQccs ZbRA== MIME-Version: 1.0 X-Received: by 10.182.115.161 with SMTP id jp1mr9233055obb.53.1434636364138; Thu, 18 Jun 2015 07:06:04 -0700 (PDT) Received: by 10.60.164.97 with HTTP; Thu, 18 Jun 2015 07:06:04 -0700 (PDT) Date: Thu, 18 Jun 2015 23:06:04 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=089e01182cf2ddd0c80518cb4e1a Archived-At: Subject: [OAUTH-WG] XARA vulnerability Paper and PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 14:06:06 -0000 --089e01182cf2ddd0c80518cb4e1a Content-Type: text/plain; charset=UTF-8 Hi OAuthers: XARA (Cross App Resource Access) paper was gaining interest here in Japan today because of the Register article[1]. I went over the attack description in the full paper [2]. The paper presents four kinds of vulnerabilities. 1. Password Stealing (Keychain) 2. Container Cracking (BundleID check bug on the part of Apple App Store) 3. IPC Interception (a. WebSocket non-authentication, and b. local oauth redirect) 4. Scheme Hijacking Of those, 3.b and 4 are relevant to us, and we kind of knew them all the way through. These are the target attack that PKCE specifically wants to address, and does address, I believe. [1] http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/ [2] https://sites.google.com/site/xaraflaws/ -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e01182cf2ddd0c80518cb4e1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi OAuthers:=C2=A0

XARA (Cross App Reso= urce Access) paper was gaining interest here in Japan today because of the = Register article[1].=C2=A0
I went over the attack description in the fu= ll paper [2].=C2=A0
The paper presents four kinds of vulnerabilitie= s.
  1. Password Stealing (Keychain)
  2. Container Cracking= (BundleID check bug on the part of Apple App Store)
  3. IPC Interc= eption (a. WebSocket non-authentication, and b. local oauth redirect)=C2=A0=
  4. Scheme Hijacking
Of those, 3.b and 4 are relevant to = us, and we kind of knew them all the way through.=C2=A0
These= are the target attack that PKCE specifically wants to address, and does ad= dress, I believe.=C2=A0




--
Nat Sakimur= a (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--089e01182cf2ddd0c80518cb4e1a-- From nobody Thu Jun 18 07:47:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6286F1B31F9 for ; Thu, 18 Jun 2015 07:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 axAQbbPgCH7i for ; Thu, 18 Jun 2015 07:47:29 -0700 (PDT) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9E81ACD94 for ; Thu, 18 Jun 2015 07:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1434638848; bh=UmhbahiCnwGR5QmCLHxfHuDNJLsq/8eiRr5S4zPDDLY=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=mXB+jI7gw10Xt2Z+Jn+i0XAT0vzKj9063+/1wHi5GHfN+ZI1l9TRcs30zqF790p2CN1eUa+7JRP9MUTAnyB8aeKglkwymmfvaM7ISHer3lgjcfyFjZ7osmhvunIHOAnsde8vrDZdQdb3JaW/sw6DCJ8SjHifNd5g2BdEAR2JMbeZc6EuJ83zY2FdUEGk0mYSXNcYf19VFhVeBG+EqcFYWyO+RbNYu0kM9L+fsIl2WHZHsAJRcF+0KRhHRwwoEOkS+o9ySPhXL8bk7ft4Gas8Y1WZaFenKRYq+up6jRJ/vaci3nC3myL6dXzKHxk/gYZ4/9MNap70pY4fDyP7UA+YkQ== Received: from [98.139.214.32] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 14:47:28 -0000 Received: from [98.139.215.229] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 14:47:28 -0000 Received: from [127.0.0.1] by omp1069.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 14:47:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 987553.3308.bm@omp1069.mail.bf1.yahoo.com X-YMail-OSG: DKp04L0VM1nWsskm4ztCCPgW3Jl.cNWlgMV9fgpiK9BIIb1A2yzKkvVfI176Oo9 V.0Viw4JtP48Y2qjAqnZUIbrPhtn.J8KFQxPvw2qhO.PpKZwhgIMlB8OWN4z_a0B9HPjn0R5WDM8 oMJxx7NVWfBr0FkdMeonmhCCzi0rNvIuB6a76D_02kKnTbS9Wj9dtQjy2.PMBdQCz1rMyZEZRLWi Cz6amc_PKDlt_8oy2kmILCHCTcxf3BZrtj2hLpqm7xvvuRCvfgC262SVA2gukeysucFOsQ0YMhI6 ABvzRNPJK98v8JAcVdUelfZFtsNcV7tRmtZz_GrCCSaRXNQZ0F2fbF0Z4Ggtig_Ug5pFZ68BdN1s kEUkD6wkPAGkthWDg312IpX843afEaA4Zrpg8oPEEcbl1CpRi8nQg6R9HgFYjT9CcDcBDwUVxRL3 Ntta9WJbyNquR5NgywXXtlcpf.2T.tSril5oY7YxB8jjJ.jgOWm2ItmAKU.pruQRm4JLRYImGlT2 oNDDwXcyw8.jtwT3UcfS_w55rNNuaYLpcFwK3W734sK5ehmuoGofni5w- Received: by 76.13.26.127; Thu, 18 Jun 2015 14:47:27 +0000 Date: Thu, 18 Jun 2015 14:47:26 +0000 (UTC) From: Bill Mills To: Nat Sakimura , oauth Message-ID: <95102368.1461467.1434638847014.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1461466_303479955.1434638847010" Archived-At: Subject: Re: [OAUTH-WG] XARA vulnerability Paper and PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 14:47:30 -0000 ------=_Part_1461466_303479955.1434638847010 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable PKCE solves a subset of this, but not the general case. =C2=A0It doesn't so= lve the FB example in the paper where the FB token is passed between apps l= ocally. It is a clear win for the OAuth code flow for example though.=20 On Thursday, June 18, 2015 7:31 AM, Nat Sakimura = wrote: =20 Hi OAuthers:=C2=A0 XARA (Cross App Resource Access) paper was gaining interest here in Japan t= oday because of the Register article[1].=C2=A0I went over the attack descri= ption in the full paper [2].=C2=A0 The paper presents four kinds of vulnerabilities. =20 - Password Stealing (Keychain) =20 - Container Cracking (BundleID check bug on the part of Apple App Store)= =20 - IPC Interception (a. WebSocket non-authentication, and b. local oauth = redirect)=C2=A0 =20 - Scheme Hijacking Of those, 3.b and 4 are relevant to us, and we kind of knew them all the wa= y through.=C2=A0 These are the target attack that PKCE specifically wants to address, and do= es address, I believe.=C2=A0 [1]=C2=A0http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0= day_mac_ios_research_blitzkrieg/[2]=C2=A0https://sites.google.com/site/xara= flaws/ --=20 Nat Sakimura (=3Dnat)Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_1461466_303479955.1434638847010 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
PKCE solves a subset of this, but not the general = case.  It doesn't solve the FB example in the paper where the FB token= is passed between apps locally.

It is a clear win = for the OAuth code flow for example though.



On Thursday, June 18, 2015 7:31 AM, Nat Sakimura <sakimura@gmail.co= m> wrote:


Hi OAuthers: 

<= div>XARA (Cross App Resource Access) paper was gaining interest here in Jap= an today because of the Register article[1]. 
I went over the atta= ck description in the full paper [2]. 
The paper presents four= kinds of vulnerabilities.
  1. Password Stealing (Keychain)
  2. Container Cracking (BundleID check bug on the part of Apple App Store= )
  3. IPC Interception (a. WebSocket non-authentication, and b. loc= al oauth redirect) 
  4. Scheme Hijacking
Of those, 3.= b and 4 are relevant to us, and we kind of knew them all the way through.&n= bsp;
These are the target attack that PKCE specifically wants= to address, and does address, I believe. 






--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>= http://nat.sakimura.org/
@_nat_en

___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/oauth


------=_Part_1461466_303479955.1434638847010-- From nobody Thu Jun 18 08:25:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE85B1B32AB for ; Thu, 18 Jun 2015 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 eNS-2d3siuHw for ; Thu, 18 Jun 2015 08:25:23 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 B5D611B32A9 for ; Thu, 18 Jun 2015 08:25:23 -0700 (PDT) Received: by oiyy130 with SMTP id y130so42863604oiy.0 for ; Thu, 18 Jun 2015 08:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0LaeH2qHVDml3KTXX1OJq5fIN5nl1Hft3Rg40YcbwDo=; b=yVyFgDYCmkkx0NWNPRNrMtNIoqn4NP4HuxmNqZc4W3PMtLdIPK87BYwwbGoUymqBq8 vHLiAQoownfFxDP2qt0pXKhkZO/njuTTAIkRv2qXDgMi0aInxxeNB4abOXUqJPWsiP+M gOPzVMA8ZG5hV5N+FIjuqDfqYRkwzgKGwn6VD3s4L9mC535xz8b9vCzPPak+vin8JrSP LkCnc87Aqr6AY0fh/OLk4OKZKzC2Cwff9f8T2AGXzBqrpOi0aO8oZaO73TPgEl/gU+J5 9TwjhgwdFqyHXQ03oq84RkPXYbRUqq22wEMjIdlf2TTqceZauH/jQNiO2OPKDJOAjHW1 iOOw== MIME-Version: 1.0 X-Received: by 10.60.74.34 with SMTP id q2mr9613501oev.68.1434641123240; Thu, 18 Jun 2015 08:25:23 -0700 (PDT) Received: by 10.60.164.97 with HTTP; Thu, 18 Jun 2015 08:25:23 -0700 (PDT) In-Reply-To: <95102368.1461467.1434638847014.JavaMail.yahoo@mail.yahoo.com> References: <95102368.1461467.1434638847014.JavaMail.yahoo@mail.yahoo.com> Date: Fri, 19 Jun 2015 00:25:23 +0900 Message-ID: From: Nat Sakimura To: Bill Mills Content-Type: multipart/alternative; boundary=001a1135fc5a87f2af0518cc6a90 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] XARA vulnerability Paper and PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 15:25:25 -0000 --001a1135fc5a87f2af0518cc6a90 Content-Type: text/plain; charset=UTF-8 Yup. Obviously, PKCE is for Code Flow and do not deal with Implicit flow. The best bet probably is stop using Implicit flow for passing tokens around among apps, unless token is capable of being sender confirmed. Nat 2015-06-18 23:47 GMT+09:00 Bill Mills : > PKCE solves a subset of this, but not the general case. It doesn't solve > the FB example in the paper where the FB token is passed between apps > locally. > > It is a clear win for the OAuth code flow for example though. > > > > On Thursday, June 18, 2015 7:31 AM, Nat Sakimura > wrote: > > > Hi OAuthers: > > XARA (Cross App Resource Access) paper was gaining interest here in Japan > today because of the Register article[1]. > I went over the attack description in the full paper [2]. > The paper presents four kinds of vulnerabilities. > > 1. Password Stealing (Keychain) > 2. Container Cracking (BundleID check bug on the part of Apple App > Store) > 3. IPC Interception (a. WebSocket non-authentication, and b. local > oauth redirect) > 4. Scheme Hijacking > > Of those, 3.b and 4 are relevant to us, and we kind of knew them all the > way through. > These are the target attack that PKCE specifically wants to address, and > does address, I believe. > > > [1] > http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_blitzkrieg/ > [2] https://sites.google.com/site/xaraflaws/ > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1135fc5a87f2af0518cc6a90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yup. Obviously, PKCE is for Code Flow and do not deal with= Implicit flow.=C2=A0
The best bet probably is stop using Implicit flow= for passing tokens around among apps, unless token is capable of being sen= der confirmed.=C2=A0

Nat

2015-06-18 23:47 GMT+09:00 Bill= Mills <wmills_92105@yahoo.com>:
PKCE solves a subset of this, but not the general = case.=C2=A0 It doesn't solve the FB example in the paper where the FB t= oken is passed between apps locally.

It is a clear win for the OAuth code flow for example though.<= /span>



On Thurs= day, June 18, 2015 7:31 AM, Nat Sakimura <sakimura@gmail.com> wrote:

Hi OAuthers:=C2=A0

XARA (Cross App Resource Access) pap= er was gaining interest here in Japan today because of the Register article= [1].=C2=A0
I went over the attack description in the full paper [2].=C2= =A0
The paper presents four kinds of vulnerabilities.
  1. = Password Stealing (Keychain)
  2. Container Cracking (BundleID check= bug on the part of Apple App Store)
  3. IPC Interception (a. WebSo= cket non-authentication, and b. local oauth redirect)=C2=A0
  4. Sch= eme Hijacking
Of those, 3.b and 4 are relevant to us, and we kind = of knew them all the way through.=C2=A0
These are the target = attack that PKCE specifically wants to address, and does address, I believe= .=C2=A0






<= /div>--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
<= a rel=3D"nofollow" href=3D"http://nat.sakimura.org/" target=3D"_blank">http= ://nat.sakimura.org/
@_nat_en

_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth





--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
<= a href=3D"http://nat.sakimura.org/" target=3D"_blank">http://nat.sakimura.o= rg/
@_nat_en
--001a1135fc5a87f2af0518cc6a90-- From nobody Thu Jun 18 10:25:17 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE641B2A62 for ; Thu, 18 Jun 2015 10:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 61UdOFG-SU9b for ; Thu, 18 Jun 2015 10:25:14 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (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 C18A01B2A2F for ; Thu, 18 Jun 2015 10:25:13 -0700 (PDT) Received: by qgf75 with SMTP id 75so28416225qgf.1 for ; Thu, 18 Jun 2015 10:25:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zqMHKuFoCT1yQ1CsKVyIl/bXnIIH2sB/Qgw9HUetrPc=; b=JxBSIlI+CZQcCiKds5DHKXlX7h4U76U1slIZW1NwvP1PM3xNbZDsxah8ZADdZ4j6Mt PaoKhraSyl+r11d3/V0bi4k+XRHjnOgnt3smVJhxcR5LIcJpexR8Deme08Us1AyKQYUF DcX98AKxgvFdoznPGTbbJqggF+oRziDt5vUkHyYnh+gLrlmoO1W+25SRP8A52B/fCuCQ MQrq4BkjQatl+uVOyxqYl/ADeimbv5xRN+b0RNdoRTXf7Qr0+dfBf4bCgzt5hvMpmeRx Y4IzRXvDCW+pdAEA6ecNK8HCXamtd9ZPATFnkHMHKi9nw6iKhegVEwfdD9BuRY11TmcW 3U7A== X-Gm-Message-State: ALoCoQkdpWV0qTglaSjFTVJ7I7Rw/8TMgEq/i2MACcDmbVGwZdFAWw4QIrcQe9ZISnFELtLLDrOU X-Received: by 10.140.147.14 with SMTP id 14mr11311539qht.97.1434648312798; Thu, 18 Jun 2015 10:25:12 -0700 (PDT) Received: from [192.168.8.102] ([181.202.9.67]) by mx.google.com with ESMTPSA id c38sm4238632qgd.33.2015.06.18.10.25.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jun 2015 10:25:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BA5D27E4-2073-483B-8DDE-22BE8D0FBF01" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: Date: Thu, 18 Jun 2015 14:23:59 -0300 Message-Id: <75CE47CF-95B4-49FE-8136-2C9351207F5B@ve7jtb.com> References: <95102368.1461467.1434638847014.JavaMail.yahoo@mail.yahoo.com> To: Nat Sakimura X-Mailer: Apple Mail (2.2098) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] XARA vulnerability Paper and PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 17:25:16 -0000 --Apple-Mail=_BA5D27E4-2073-483B-8DDE-22BE8D0FBF01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Passing the FB token between apps on the device is not a real use of the = implicit flow, Facebook may be reusing the pattern in an insecure way. The NAPPS WG at the OIDF recognized that was insecure a long time ago. = We are looking to use the S256 pkce transform to secure similar sorts of = on device communication of code between a Oauth proxy on the device and = a app. John B. > On Jun 18, 2015, at 12:25 PM, Nat Sakimura wrote: >=20 > Yup. Obviously, PKCE is for Code Flow and do not deal with Implicit = flow.=20 > The best bet probably is stop using Implicit flow for passing tokens = around among apps, unless token is capable of being sender confirmed.=20 >=20 > Nat >=20 > 2015-06-18 23:47 GMT+09:00 Bill Mills >: > PKCE solves a subset of this, but not the general case. It doesn't = solve the FB example in the paper where the FB token is passed between = apps locally. >=20 > It is a clear win for the OAuth code flow for example though. >=20 >=20 >=20 > On Thursday, June 18, 2015 7:31 AM, Nat Sakimura > wrote: >=20 >=20 > Hi OAuthers:=20 >=20 > XARA (Cross App Resource Access) paper was gaining interest here in = Japan today because of the Register article[1].=20 > I went over the attack description in the full paper [2].=20 > The paper presents four kinds of vulnerabilities. > Password Stealing (Keychain) > Container Cracking (BundleID check bug on the part of Apple App Store) > IPC Interception (a. WebSocket non-authentication, and b. local oauth = redirect)=20 > Scheme Hijacking > Of those, 3.b and 4 are relevant to us, and we kind of knew them all = the way through.=20 > These are the target attack that PKCE specifically wants to address, = and does address, I believe.=20 >=20 >=20 > [1] = http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_= ios_research_blitzkrieg/ = > [2] https://sites.google.com/site/xaraflaws/ = >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_BA5D27E4-2073-483B-8DDE-22BE8D0FBF01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Passing the FB token between apps on the device is not a real = use of the implicit flow, Facebook may be reusing the pattern in an = insecure way.

The = NAPPS WG at the OIDF recognized that was insecure a long time ago. =  We are looking to use the S256 pkce transform to secure similar = sorts of on device communication of code between a Oauth proxy on the = device and a app.

John B.

On = Jun 18, 2015, at 12:25 PM, Nat Sakimura <sakimura@gmail.com> = wrote:

Yup. Obviously, PKCE is for Code Flow and do not = deal with Implicit flow. 
The best bet probably is = stop using Implicit flow for passing tokens around among apps, unless = token is capable of being sender confirmed. 
Nat

2015-06-18= 23:47 GMT+09:00 Bill Mills <wmills_92105@yahoo.com>:
PKCE solves a subset of this, but not the general case.  = It doesn't solve the FB example in the paper where the FB token is = passed between apps locally.

It= is a clear win for the OAuth code flow for example though.
=


On Thursday, June 18, 2015 7:31 AM, Nat Sakimura <sakimura@gmail.com> wrote:
 =


Hi OAuthers: 

XARA (Cross App Resource Access) paper was gaining interest = here in Japan today because of the Register article[1]. 
I went over the attack description in the full paper = [2]. 
The paper presents four kinds = of vulnerabilities.
  1. Password Stealing = (Keychain)
  2. Container Cracking = (BundleID check bug on the part of Apple App Store)
    3. IPC Interception (a. WebSocket non-authentication, and b. = local oauth redirect) 
  3. Scheme = Hijacking
Of those, 3.b and 4 are relevant to us, and we kind = of knew them all the way through. 
These are the target attack that PKCE specifically wants to = address, and does address, I believe. 


[1] http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_dro= p_0day_mac_ios_research_blitzkrieg/
[2] https://sites.google.com/site/xaraflaws/




--
Nat Sakimura = (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


=



--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_BA5D27E4-2073-483B-8DDE-22BE8D0FBF01-- From nobody Thu Jun 18 11:08:43 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5771B2B6B for ; Thu, 18 Jun 2015 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 0bxM2mpyN87B for ; Thu, 18 Jun 2015 11:08:39 -0700 (PDT) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (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 8E7571B2BA0 for ; Thu, 18 Jun 2015 11:08:36 -0700 (PDT) Received: by qkbp125 with SMTP id p125so44030326qkb.2 for ; Thu, 18 Jun 2015 11:08:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=nc4rQ2QRjGLV/sXTsF57wla4EiZ/ihc0leuOrp1PnyY=; b=P7Ok937BhRp9149ut9cyv5PvC4pZ3OLFx6xNigMk1SPY1dTadu3ZuWUp2Dn+eoyc2T 756iwiAtYwoxMEVafR3UjxuUQuIJk6TLSOpHzq7x8HhV8ZYSAyHfxBODvd7dIvi8cJ8g YU8o8TQMJ/NboayFrcNbL6Ujb7tzUk3EwbnLbW0PhzdJdMf48lszXP59eK7XN3Ap5d/W 90YrLtsHC1aB9sR/ia9SI8nGaQ6MAK29tszOxqhVth1tk7jMqzbCtM13NFKqIc5BrP8O h3O/YpMX1vM6EARFMn4lPxnn8bLB9loVjCLUU/G38vPt2xOeuiegBfrNpqFBmjY1WllA +mMQ== X-Gm-Message-State: ALoCoQkKmXNLWIxx4lnie1JQAZ38jLTRA7hEPOUR1sHTMvgSzhNJe5vVM3EefB3aB7oS1IxAHjGE X-Received: by 10.140.21.81 with SMTP id 75mr16121251qgk.86.1434650915508; Thu, 18 Jun 2015 11:08:35 -0700 (PDT) Received: from [192.168.8.102] ([181.202.9.67]) by mx.google.com with ESMTPSA id n132sm4254011qhb.12.2015.06.18.11.08.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jun 2015 11:08:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: <5579EA2F.5020404@gmx.net> Date: Thu, 18 Jun 2015 15:08:19 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <506CD550-75C3-4354-8FCB-40C0921F2A81@ve7jtb.com> References: <20150611184955.1618.38149.idtracker@ietfa.amsl.com> <5579DB31.30807@gmx.net> <5579EA2F.5020404@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-oauth-spop@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-spop.shepherd@ietf.org, The IESG , Barry Leiba , oauth WG , draft-ietf-oauth-spop.ad@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-spop-12: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 18:08:40 -0000 Just a FYI, the issue addressed in this draft hit the media this week as = a result of this paper = https://drive.google.com/file/d/0BxxXk1d3yyuZOFlsdkNMSGswSGs/view The attack we have been discussing is in Section 3.4. John B. > On Jun 11, 2015, at 5:06 PM, Hannes Tschofenig = wrote: >=20 > Sounds good to me, Barry! >=20 > On 06/11/2015 09:10 PM, Barry Leiba wrote: >>> Ah, got it. Then it would be good for (4) to say that, maybe just = by >>>> adding to the end, "This mechanism does not protect again the more >>>> sophisticated attack." Sound OK? >> That should be "against", of course, not "again". I hate tupos. >=20 From nobody Thu Jun 18 11:21:27 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F191B3344 for ; Thu, 18 Jun 2015 11:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 0rmEnSqm8uRS for ; Thu, 18 Jun 2015 11:21:25 -0700 (PDT) Received: from nm49-vm10.bullet.mail.bf1.yahoo.com (nm49-vm10.bullet.mail.bf1.yahoo.com [216.109.114.251]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBA91B3346 for ; Thu, 18 Jun 2015 11:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1434651659; bh=ceZPMUXg4/Rxo5QvZnsMG47dbb8zWSRnivBUAgxQLfQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Vv5p9wplrZkkommoFjGxX4mUmt+uUOzOz0xtm8EcXd50IGKQDJfqzJxkkLQuv6/lU56ovrxtvIN5T3rRY+4Ly/J0rEemdnokW36Cws9XwCtEacODtEneY+HBdff4RoRoN9loJ5BqKGm8iWR7UPVpPATKh8cVWmpO92rQczoo62qHlp0zTBAphop1wclAkNh9CmoAPBnEcrxYvGeGDl9Vy+7NX7RdDUb1nV7VXPvjXll9mkhZzR1tOv4waASa9StXMo5pWPvkGskm2w5UkNIjFHaYx5GKb7Ee16n8HGb8vyFan02xEHxdKofYWLjnH93flxHaBt5suKxb9ElqNd8kLA== Received: from [98.139.215.141] by nm49.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 18:20:59 -0000 Received: from [98.139.215.250] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 18:20:59 -0000 Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP; 18 Jun 2015 18:20:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 575824.29519.bm@omp1063.mail.bf1.yahoo.com X-YMail-OSG: 3taxQPYVM1mbo6GrF5MwQKXVJNtK0qi.Z6cW.9StMFssntFta7vfkkZdBfXsVr. Qu_YMtDrSA3FF62r8cPRcuXCbnWhpDwR41OpdTC5hq6KFRHU_xsLED3pgiD2FsHQaaZtNBUK6Gws COfjR06T9ZvzUwfb2Jrf_TZm3PdOvBD7HJbErLYAiMPtsreWZj3KI41.3njUTREMjYXiFyw1jDEZ .CI2nZ2GKynrc0Cr.WuqyxbXXB1H__fJxq5250cLo5ud12BFBdMjtsKTzfJhqLK.fb8lFX5O4ADu BAxua3s_ni0Gs87qv.CxvUZJ3QFPmbapMaBmmhRa0.m6FjdksxYTrr_XK440nsyLahBdlrd7HZ0D LBue6B2cDwC6isAQgVKn8MIyvMqoC2PiGlZHzqf5ep1gzK4QsoBA1UZrM33o7OusZps2AFv2WTxH EZCBQl55FjLYCG1WtXj.WynYSHnQgYvO_uCzNATDGeClYu5QZChfzLJs8u_5B2_WJO9ergKKa4UP YuENNvHsJuEQ7z.pFfdsR Received: by 76.13.26.66; Thu, 18 Jun 2015 18:20:59 +0000 Date: Thu, 18 Jun 2015 18:20:58 +0000 (UTC) From: Bill Mills To: John Bradley , Nat Sakimura Message-ID: <582606189.1617476.1434651658674.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <75CE47CF-95B4-49FE-8136-2C9351207F5B@ve7jtb.com> References: <75CE47CF-95B4-49FE-8136-2C9351207F5B@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1617475_591608839.1434651658664" Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] XARA vulnerability Paper and PKCE X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 18:21:27 -0000 ------=_Part_1617475_591608839.1434651658664 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There are other bits of sensitive info that might pass via redirect and be = intercepted due to the scheme handler insecurity. =C2=A0It's not just OAuth= or other such tokens, although they are significant.=20 On Thursday, June 18, 2015 10:25 AM, John Bradley = wrote: =20 Passing the FB token between apps on the device is not a real use of the i= mplicit flow, Facebook may be reusing the pattern in an insecure way. The NAPPS WG at the OIDF recognized that was insecure a long time ago. =C2= =A0We are looking to use the S256 pkce transform to secure similar sorts of= on device communication of code between a Oauth proxy on the device and a = app. John B. On Jun 18, 2015, at 12:25 PM, Nat Sakimura wrote: Yup. Obviously, PKCE is for Code Flow and do not deal with Implicit flow.= =C2=A0The best bet probably is stop using Implicit flow for passing tokens = around among apps, unless token is capable of being sender confirmed.=C2=A0 Nat 2015-06-18 23:47 GMT+09:00 Bill Mills : PKCE solves a subset of this, but not the general case.=C2=A0 It doesn't so= lve the FB example in the paper where the FB token is passed between apps l= ocally. It is a clear win for the OAuth code flow for example though.=20 On Thursday, June 18, 2015 7:31 AM, Nat Sakimura = wrote: =20 Hi OAuthers:=C2=A0 XARA (Cross App Resource Access) paper was gaining interest here in Japan t= oday because of the Register article[1].=C2=A0I went over the attack descri= ption in the full paper [2].=C2=A0 The paper presents four kinds of vulnerabilities. =20 - Password Stealing (Keychain) =20 - Container Cracking (BundleID check bug on the part of Apple App Store)= =20 - IPC Interception (a. WebSocket non-authentication, and b. local oauth = redirect)=C2=A0 =20 - Scheme Hijacking Of those, 3.b and 4 are relevant to us, and we kind of knew them all the wa= y through.=C2=A0 These are the target attack that PKCE specifically wants to address, and do= es address, I believe.=C2=A0 [1]=C2=A0http://www.theregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0= day_mac_ios_research_blitzkrieg/[2]=C2=A0https://sites.google.com/site/xara= flaws/ --=20 Nat Sakimura (=3Dnat)Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 --=20 Nat Sakimura (=3Dnat)Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_1617475_591608839.1434651658664 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There are other= bits of sensitive info that might pass via redirect and be intercepted due= to the scheme handler insecurity.  It's not just OAuth or other such = tokens, although they are significant.



On Thur= sday, June 18, 2015 10:25 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:=


Passing the FB token between apps on the device is not a r= eal use of the implicit flow, Facebook may be reusing the pattern in an ins= ecure way.

The NAPPS WG at the OIDF recogniz= ed that was insecure a long time ago.  We are looking to use the S256 = pkce transform to secure similar sorts of on device communication of code b= etween a Oauth proxy on the device and a app.

John B.

On Jun 18, 2= 015, at 12:25 PM, Nat Sakimura <sakimura@gmail.com> wrote:
<= br clear=3D"none" class=3D"yiv4584033630Apple-interchange-newline">
Yup. Obviousl= y, PKCE is for Code Flow and do not deal with Implicit flow. 
The best bet probably is stop using Implicit flow for p= assing tokens around among apps, unless token is capable of being sender co= nfirmed. 

Nat

2015-06-18 23:47 GMT+09:00 Bill M= ills <wmills_92105@yah= oo.com>:
PKCE solves a subset of this, but not the general case.  It does= n't solve the FB example in the paper where the FB token is passed between = apps locally.

It is a clear win for the= OAuth code flow for example though.



On Thursday, June 18, 2015 7:31 AM,= Nat Sakimura <sakimura@gmail.com> wrote:


<= div class=3D"yiv4584033630">
Hi OAu= thers: 

XARA (Cross App Resource Access= ) paper was gaining interest here in Japan today because of the Register ar= ticle[1]. 
I went over the attack descript= ion in the full paper [2]. 
=
The paper presents four kinds of vulnerabiliti= es.
  1. Password S= tealing (Keychain)
  2. Container Cracking (BundleID check bug on the part of Ap= ple App Store)
  3. IPC Interception (a. WebSocket non-authentication, and b. lo= cal oauth redirect) 
    4. Scheme Hijacking
Of those, 3.b and 4 are= relevant to us, and we kind of knew them all the way through. 
Thes= e are the target attack that PKCE specifically wants to address, and does a= ddress, I believe. 


[1] http://www.t= heregister.co.uk/2015/06/17/apple_hosed_boffins_drop_0day_mac_ios_research_= blitzkrieg/
[2] https://sites.google.com/site/xaraflaws= /




--
Nat Sakimura (=3Dnat)
Chairman, OpenI= D Foundation
http://nat.sakimura.org/
@_nat_en

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/oauth



<= /div>



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/= mailman/listinfo/oauth

<= /div>

------=_Part_1617475_591608839.1434651658664-- From nobody Mon Jun 22 14:42:49 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EEF1A6EDB; Mon, 22 Jun 2015 14:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 4rWnR63flyGG; Mon, 22 Jun 2015 14:42:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C83F1A7032; Mon, 22 Jun 2015 14:42:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150622214243.29139.53649.idtracker@ietfa.amsl.com> Date: Mon, 22 Jun 2015 14:42:43 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-introspection-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 21:42:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Token Introspection Author : Justin Richer Filename : draft-ietf-oauth-introspection-10.txt Pages : 17 Date : 2015-06-22 Abstract: This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-introspection-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 22 14:52:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6CD1AD36B; Mon, 22 Jun 2015 14:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 9H1jb8jhYN-r; Mon, 22 Jun 2015 14:52:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D221E1AD364; Mon, 22 Jun 2015 14:52:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150622215210.2180.203.idtracker@ietfa.amsl.com> Date: Mon, 22 Jun 2015 14:52:10 -0700 Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-10: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 21:52:29 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-introspection-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and most of my comments. The important comment that still remains is this: -- Section 3.1 -- I'd REALLY like to see us stop trying to tell IANA how to handle review by designated experts.  This should be re-cast as instructions to the DE (to make sure that the mailing list is consulted), and IANA should be left to handle the expert review with their existing process, which works fine. While we're at it, it would be nice to have some further instruction to the DEs about what they should be looking at when deciding whether to approve a request.  There's some very minimal instruction under "name" in the template, but that's all.  Is there nothing more to say? For the spop document, I suggested the text change below. Something similar for this document would be great: For the spop document, not this one!: OLD NEW Additional code_challenge_method types for use with the authorization endpoint are registered using the Specification Required policy [RFC5226], which includes review of the request by one or more Designated Experts. The DEs will ensure there is at least a two-week review of the request on the oauth-ext-review@ietf.org mailing list, and that any discussion on that list converges before they respond to the request. To allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that an acceptable specification will be published. Discussion on the oauth-ext-review@ietf.org mailing list should use an appropriate subject, such as "Request for PKCE code_challenge_method: example"). The Designated Expert(s) should consider the discussion on the mailing list, as well as <> when evaluating registration requests. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. END From nobody Mon Jun 22 17:51:56 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CDE1B3132; Mon, 22 Jun 2015 17:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 E1-vB3jSjBUS; Mon, 22 Jun 2015 17:51:48 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804031B3136; Mon, 22 Jun 2015 17:51:47 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-36-5588ada234c3 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id BE.28.01570.2ADA8855; Mon, 22 Jun 2015 20:51:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t5N0piI1016504; Mon, 22 Jun 2015 20:51:45 -0400 Received: from macbook-pro.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5N0pFIE003545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 20:51:43 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_A7984880-C252-4B8C-9994-4126919FCFCD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: Date: Mon, 22 Jun 2015 20:51:28 -0400 Message-Id: <07ABEE40-9755-4CE0-A3FB-4626C0444C61@mit.edu> References: <20150608164044.24189.13985.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixCmqrLtobUeowbX3vBbTz/xltDi76Ta7 xYrl5RYvFu9ktpjxZyKzxe25K9ksTr59xebA7vHlyUsmjyVLfjIFMEVx2aSk5mSWpRbp2yVw Zcz58pC1YHkzY0XbhuAGxpP5XYycHBICJhIn2pcyQdhiEhfurWfrYuTiEBJYzCTxY/oMFghn I6PEwaXHmCGcx0wSE/49YAdpYRZIkHh65wEziM0roCfx6OljsLiwQIHE5HMdbCA2m4CqxPyV t8BWcApYS7w7dQwozsHBAhSf+QVsAbPAL0aJJ0d2skPMsZKYtXwLK4gtBDTn3u0WsPkiQPVX j/0A65UQkJX4ulVuAqPALCRXzEJyBURcW2LZwtfMELamxP7u5SyY4hoSnd8msi5gZFvFKJuS W6Wbm5iZU5yarFucnJiXl1qka6iXm1mil5pSuokRHCGSPDsY3xxUOsQowMGoxMNbMLkjVIg1 say4MvcQoyQHk5Io75oGoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3qlzgHK8KYmVValF+TAp aQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8nmuAGgWLUtNTK9Iyc0oQ0kwcnCDDeYCG 31wNMry4IDG3ODMdIn+KUVFKnNcSpFkAJJFRmgfXC0tgrxjFgV4R5l0JUsUDTH5w3a+ABjMB Df6S2wYyuCQRISXVwNgZl7C573d7kuG/wpSZIoIbQjKuntDx3RwQtvjGvX5RqSnvjaMXm/f4 WPyw6tuZXDpvxfl0nsT0nOSUToXSHbeOzuBdcNl80d0M3eryM7PNN92rkRP/H/BC9+V9pzzO ELMHnGbzp/5wKr3xKXLRX+avOmJreI8HhYi5654paC7zLeK/9dDQUYmlOCPRUIu5qDgRAFDw bU07AwAA Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-introspection-09: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 00:51:51 -0000 --Apple-Mail=_A7984880-C252-4B8C-9994-4126919FCFCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alissa, I=E2=80=99ve uploaded a new draft that should address your comments = below: Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 = Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-10.tx= t = Please let me know if you have any further questions, =E2=80=94 Justin > On Jun 11, 2015, at 5:00 PM, Justin Richer wrote: >=20 > Hi Alissa, thanks for your review. Responses are inline. >=20 >> On Jun 8, 2015, at 9:40 AM, Alissa Cooper wrote: >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-oauth-introspection-09: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> =3D Section 2.1 =3D >> "The endpoint MAY allow other parameters to provide further context = to >> the query. For instance, an authorization service may need to know >> the IP address of the client accessing the protected resource in >> order to determine the appropriateness of the token being = presented." >>=20 >> How does the protected resource know whether it needs to include such >> additional parameters or not? >> What is meant by the "appropriateness" of >> the token?=20 >>=20 >> In general if we're talking about a piece of data that could be = sensitive >> like client IP address, it would be better for there to be specific >> guidelines to direct protected resources as to when this information >> needs to be sent. I note that Section 5 basically says such >> considerations are out of scope, but if this specific example is to = be >> provided here then they seem in scope to me. >=20 > We are trying to leave the door open to extensions and adaptations of = this protocol, specifically around the protected resource passing along = information about the client=E2=80=99s request. The AS might be able to = help the RS detect funny business on the client=E2=80=99s behalf (i.e., = whether it=E2=80=99s appropriate for the client to presenting the token = in this context) if it has that information.=20 >=20 > The example isn=E2=80=99t supposed to be normative or pull extra = considerations into scope of this protocol but instead to point out = where it could go. >=20 > Do you have a suggestion for rewording this? Perhaps it would be best = to move all of this language to the security considerations section, as = it=E2=80=99s more guidance for what extensions to this spec would need = to think about as opposed to what pure implementations of this spec = would need. >=20 >>=20 >> =3D Section 5 =3D >> "One way to limit disclosure is to require >> authorization to call the introspection endpoint and to limit calls >> to only registered and trusted protected resource servers." >>=20 >> I thought Section 2.1 made authorization to call the introspection >> endpoint mandatory. This makes it sound like it's optional. Which is = it? >=20 > Thanks for this catch. Authorization used to be optional, and it looks = like we missed updating this text. I=E2=80=99ll fix that in the next = revision. >=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> =3D Section 1.1 =3D >> There is no reference to RFC2119 here, which may be okay but most >> documents include it if they use normative language (I think). >>=20 >=20 > Not sure how that happened, this should have been included by the = xml2rfc tooling, I=E2=80=99ll look into it. >=20 >> =3D Section 2 =3D >> "The >> definition of an active token is up to the authorization server, but >> this is commonly a token that has been issued by this authorization >> server, is not expired, has not been revoked, and is within the >> purview of the protected resource making the introspection call." >>=20 >> Is "within the purview" a term of art for OAuth 2.0? Is there a more >> specific way to describe what is meant here? Also, I note that in the >> description of the "active" member in Section 2.2, this criterion is = not >> listed. It seems like these should be aligned. >=20 > It is not a term of art in OAuth, and I can change that to =E2=80=9Cis = able to be used at the protected resource=E2=80=9D if that=E2=80=99s = clearer. I will also add that to the list of checks about the active = value, thanks. >=20 >>=20 >> =3D Section 2.2 =3D >> "Note that in order to avoid disclosing too much of the >> authorization server's state to a third party, the authorization >> server SHOULD NOT include any additional information about an >> inactive token, including why the token is inactive." >>=20 >> Seems like this should be a MUST NOT unless there's some reason for >> providing anything other than active set to false. Same comment = applies >> in Section 4. >=20 > That=E2=80=99s why it=E2=80=99s SHOULD =E2=80=94 which translates, = roughly, to =E2=80=9Cdo it this way unless you=E2=80=99ve got a really, = really good reason not to=E2=80=9D. >=20 >>=20 >> =3D Section 2.3 =3D >> It seems like there is another error condition and I'm wondering if = its >> handling needs to be specified. Per my question in Section 2.1, if = it's >> possible that the request is properly formed but is missing some >> additional information that the authorization server needs to = evaluate >> it, should there be an error condition specified for that case? >>=20 >=20 > Not by this specification, since there isn=E2=80=99t a mechanism for = the protected resource to figure out automatically what to do next. If = there=E2=80=99s a future extension specifying this extra information, it = can define its own value. >=20 > =E2=80=94 Justin >=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_A7984880-C252-4B8C-9994-4126919FCFCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Alissa,

I=E2=80=99ve uploaded a new draft that = should address your comments below:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10

Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspe= ction-10.txt

Please let me know if you have any further = questions,
 =E2=80=94 Justin

On Jun 11, 2015, at 5:00 PM, Justin Richer = <jricher@MIT.EDU> = wrote:

Hi = Alissa, thanks for your review. Responses are inline.

On Jun 8, 2015, at 9:40 = AM, Alissa Cooper <alissa@cooperw.in> wrote:

Alissa Cooper has entered the following ballot position = for
draft-ietf-oauth-introspection-09: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection= /



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

=3D Section 2.1 =3D
"The endpoint MAY allow other parameters to provide further = context to
 the query.  For instance, an = authorization service may need to know
 the IP = address of the client accessing the protected resource in
=  order to determine the appropriateness of the token being = presented."

How does the protected resource = know whether it needs to include such
additional = parameters or not?
What is meant by the "appropriateness" = of
the token?

In general if = we're talking about a piece of data that could be sensitive
like client IP address, it would be better for there to be = specific
guidelines to direct protected resources as to = when this information
needs to be sent. I note that = Section 5 basically says such
considerations are out of = scope, but if this specific example is to be
provided here = then they seem in scope to me.

We are trying to leave the door open to extensions and = adaptations of this protocol, specifically around the protected resource = passing along information about the client=E2=80=99s request. The AS = might be able to help the RS detect funny business on the client=E2=80=99s= behalf (i.e., whether it=E2=80=99s appropriate for the client to = presenting the token in this context) if it has that information.

The example isn=E2=80=99t supposed to be = normative or pull extra considerations into scope of this protocol but = instead to point out where it could go.

Do = you have a suggestion for rewording this? Perhaps it would be best to = move all of this language to the security considerations section, as = it=E2=80=99s more guidance for what extensions to this spec would need = to think about as opposed to what pure implementations of this spec = would need.


=3D Section 5 =3D
"One way to = limit disclosure is to require
 authorization to = call the introspection endpoint and to limit calls
=  to only registered and trusted protected resource servers."

I thought Section 2.1 made authorization to = call the introspection
endpoint mandatory. This makes it = sound like it's optional. Which is it?

Thanks for this catch. Authorization used to be optional, and = it looks like we missed updating this text. I=E2=80=99ll fix that in the = next revision.



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

=3D Section 1.1 =3D
There is no reference to RFC2119 here, which may be okay but = most
documents include it if they use normative language = (I think).


Not = sure how that happened, this should have been included by the xml2rfc = tooling, I=E2=80=99ll look into it.

=3D Section 2 =3D
"The
 definition of an active token is up = to the authorization server, but
 this is commonly a = token that has been issued by this authorization
=  server, is not expired, has not been revoked, and is within the
 purview of the protected resource making the = introspection call."

Is "within the = purview" a term of art for OAuth 2.0? Is there a more
specific way to describe what is meant here? Also, I note = that in the
description of the "active" member in Section = 2.2, this criterion is not
listed. It seems like these = should be aligned.

It is not a = term of art in OAuth, and I can change that to =E2=80=9Cis able to be = used at the protected resource=E2=80=9D if that=E2=80=99s clearer. I = will also add that to the list of checks about the active value, = thanks.


=3D Section 2.2 =3D
"Note that = in order to avoid disclosing too much of the
=  authorization server's state to a third party, the = authorization
 server SHOULD NOT include any = additional information about an
 inactive token, = including why the token is inactive."

Seems = like this should be a MUST NOT unless there's some reason for
providing anything other than active set to false. Same = comment applies
in Section 4.
That=E2=80=99s why it=E2=80=99s SHOULD =E2=80=94 which = translates, roughly, to =E2=80=9Cdo it this way unless you=E2=80=99ve = got a really, really good reason not to=E2=80=9D.


=3D = Section 2.3 =3D
It seems like there is another error = condition and I'm wondering if its
handling needs to be = specified. Per my question in Section 2.1, if it's
possible = that the request is properly formed but is missing some
additional information that the authorization server needs to = evaluate
it, should there be an error condition specified = for that case?


Not by this specification, since there isn=E2=80=99t a = mechanism for the protected resource to figure out automatically what to = do next. If there=E2=80=99s a future extension specifying this extra = information, it can define its own value.

= =E2=80=94 Justin


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_A7984880-C252-4B8C-9994-4126919FCFCD-- From nobody Mon Jun 22 17:52:31 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0381B311D; Mon, 22 Jun 2015 17:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hVGxr5jsjkdQ; Mon, 22 Jun 2015 17:52:13 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183531B3135; Mon, 22 Jun 2015 17:52:07 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-1e-5588adb5f40f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id A3.3B.09777.5BDA8855; Mon, 22 Jun 2015 20:52:05 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t5N0q4Mj009685; Mon, 22 Jun 2015 20:52:04 -0400 Received: from macbook-pro.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5N0pFIF003545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 20:52:03 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_8FAFA636-A128-4336-8ED7-1B32C4D8644C" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: Date: Mon, 22 Jun 2015 20:51:55 -0400 Message-Id: <6B0C7F15-7DD0-4CCE-A3F1-E76007314B02@mit.edu> References: <20150608123617.6617.42932.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixG6nrrt1bUeowZm/5haHFl9itTi76Ta7 xYrl5RYvFu9ktpjxZyKzxe25K9ksTr59xebA7tGyqpfZY8mSn0wBTFFcNimpOZllqUX6dglc GZ1th1gKtmhWXLu8hqWB8bhyFyMnh4SAicSeRf9ZIGwxiQv31rN1MXJxCAksZpLYvXYlM4Sz kVFifdNbRgjnMZPEw2UvwVqYBRIkfqz5yQpi8wroSTx6+pgdxBYWSJc4/vAtG4jNJqAqMX/l LaYuRg4OToFAiRcreUHCLEDhI/NeMIHMZBb4xSjRvPMrE8QcK4mm3kNMEMtWMEmcP7MMbJmI gKbE889TwAZJCMhKfN0qN4FRYBaSM2YhOQMiri2xbOFrZghbU2J/93IWTHENic5vE1kXMLKt YpRNya3SzU3MzClOTdYtTk7My0st0jXWy80s0UtNKd3ECIoRTkm+HYxfDyodYhTgYFTi4S2Y 3BEqxJpYVlyZe4hRkoNJSZR3TQNQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv1DlAOd6UxMqq 1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCd62NUCNgkWp6akVaZk5JQhpJg5O kOE8QMNPgtTwFhck5hZnpkPkTzEqSonzrgdJCIAkMkrz4HphKewVozjQK8K8D0CqeIDpD677 FdBgJqDBX3LbQAaXJCKkpBoYI48/8cqUUXrN4bXGrDDhe7zKbXuZ5LM5e9t8ObebqrQ3eM0u Ed7344GuyHIjH0vldQLLJqk+trH9W+DeFvdUQMtgg3XhxSxztTkfPbeJ26de0WheuokrqVOH jencEUlrVe83BWszshP2P16w5oCLtkHqoeW5GuvMly5PWSz0Jfynm8WiLGYlluKMREMt5qLi RADv76udPAMAAA== Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "" Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 00:52:18 -0000 --Apple-Mail=_8FAFA636-A128-4336-8ED7-1B32C4D8644C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Barry, I=E2=80=99ve uploaded a new draft that should address your comments = below: Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 = Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-10.tx= t = Hopefully this will be sufficient to clear the DISCUSS. Please let me know if you have any further questions, =E2=80=94 Justin > On Jun 11, 2015, at 5:32 PM, Barry Leiba = wrote: >=20 >>> 1. Why is GET an optimization? It has privacy disadvantages, and I >>> don't see any advantages. >>>=20 >>> 2. This "tight coupling" thing is something that I think weakens the >>> interoperability of the OAuth protocol in general, and I've never >>> liked it. In this case, in particular, I don't see any advantage to >>> it, and I don't understand why it's useful to have an option that = only >>> works if you have inside knowledge, for no benefit. >>>=20 >>> Why is it ever good to have clients that only work with certain >>> servers, when it's just as easy to make sure that all clients work >>> with all servers? >>=20 >> I can see your point here, and others have raised it as well. Part of >> the reason the GET option is there is that most (if not all) of the >> existing implementations of this protocol enable it anyway. Having >> thought about this a bit, I would be fine with simply saying that = POST >> is required and remaining silent on other methods in the main = section. >> We can keep the warnings against also allowing GET in the security >> considerations. Will that work? >=20 > That will be of great excellence all 'round. Thanks! >=20 > Barry --Apple-Mail=_8FAFA636-A128-4336-8ED7-1B32C4D8644C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Barry,

I=E2=80=99ve uploaded a new draft that = should address your comments below:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10

Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspe= ction-10.txt

Hopefully this will be sufficient to clear the = DISCUSS.

Please = let me know if you have any further questions,
 =E2=80=94 Justin

On Jun 11, 2015, at 5:32 PM, Barry Leiba <barryleiba@computer.org> wrote:

1. Why is = GET an optimization?  It has privacy disadvantages, and I
don't see any advantages.

2. = This "tight coupling" thing is something that I think weakens the
interoperability of the OAuth protocol in general, and I've = never
liked it.  In this case, in particular, I don't = see any advantage to
it, and I don't understand why it's = useful to have an option that only
works if you have = inside knowledge, for no benefit.

Why is it = ever good to have clients that only work with certain
servers, when it's just as easy to make sure that all clients = work
with all servers?

I can see your point here, and others have raised it as well. = Part of
the reason the GET option is there is that most = (if not all) of the
existing implementations of this = protocol enable it anyway. Having
thought about this a = bit, I would be fine with simply saying that POST
is = required and remaining silent on other methods in the main section.
We can keep the warnings against also allowing GET in the = security
considerations. Will that work?

That will be of great excellence = all 'round.  Thanks!

Barry

= --Apple-Mail=_8FAFA636-A128-4336-8ED7-1B32C4D8644C-- From nobody Mon Jun 22 17:52:52 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6F61B3132; Mon, 22 Jun 2015 17:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xZtaOFtORaUF; Mon, 22 Jun 2015 17:52:31 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id DE4071B313C; Mon, 22 Jun 2015 17:52:30 -0700 (PDT) X-AuditID: 12074422-f79d26d0000026d6-d0-5588adce106f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.1C.09942.ECDA8855; Mon, 22 Jun 2015 20:52:30 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t5N0qSnC016589; Mon, 22 Jun 2015 20:52:29 -0400 Received: from macbook-pro.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5N0pFIG003545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 20:52:27 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_7BF79A10-DBF3-41DB-ABA5-CC353331B850" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: Date: Mon, 22 Jun 2015 20:52:18 -0400 Message-Id: <075DE2D1-2484-4EFA-BDE0-9F531B9A961E@mit.edu> References: <20150610002416.13636.71337.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUixCmqrHtubUeowf17vBbzO0+zW5zddJvd YsXycosXi3cyW8z4M5HZ4vbclWwWJ9++YnNg91iy5CeTx6ydT1gCmKK4bFJSczLLUov07RK4 Mq5d/MxccDmt4kJ7J1sD49PwLkZODgkBE4m/Pc0sELaYxIV769m6GLk4hAQWM0ksuPaKCcLZ yChxcfNuJpAqIYHHTBK722K6GDk4mAUSJJ488AQJ8wroSTx6+pgdxBYWyJD48OQVWDmbgKrE /JW3mEDKOQWsJfY1gpWzAIU37F3NCDKeWeAXo8STIzvZIeZYSdza/JMFYlWBxMslx8HmiAgo STxv3soCMkdCQFbi61a5CYwCsxCOmIXkCBCbWUBbYtnC18wQtqbE/u7lLJjiGhKd3yayLmBk W8Uom5JbpZubmJlTnJqsW5ycmJeXWqRrqpebWaKXmlK6iREUG+wuSjsYfx5UOsQowMGoxMNb MLkjVIg1say4MvcQoyQHk5Io76o1QCG+pPyUyozE4oz4otKc1OJDjBIczEoivFPnAOV4UxIr q1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4r4AMFSxKTU+tSMvMKUFIM3Fw ggznARrusBZkeHFBYm5xZjpE/hSjopQ473qQZgGQREZpHlwvLHW9YhQHekWYVxukigeY9uC6 XwENZgIa/CW3DWRwSSJCSqqBseDH5YPR0Xu2qy9W6P3kKb/l9NMWkQX8JteEZl10vfPX/Hej gdxVSaPd0YHqM/Wf/1n5UDVq0/sQS1/e0m9H1FJDOJY5Znc4qdR8/zVn7qKqw5F+V562Z2j4 bJm+Lsb8EVfpYVeXHyqBdnPmtZ/fqim+7mfBDcngn/X8J52W5i4/8rqrnG+prhJLcUaioRZz UXEiAJ4xcOw4AwAA Archived-At: Cc: draft-ietf-oauth-introspection@ietf.org, draft-ietf-oauth-introspection.ad@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-introspection.shepherd@ietf.org, The IESG , "" Subject: Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-introspection-09: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 00:52:40 -0000 --Apple-Mail=_7BF79A10-DBF3-41DB-ABA5-CC353331B850 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben, I=E2=80=99ve uploaded a new draft that should address your comments = below: Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 = Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-10.tx= t = Please let me know if you have any further questions, =E2=80=94 Justin > On Jun 11, 2015, at 6:25 PM, Justin Richer wrote: >=20 > Ben, thanks for your review. Comments inline. >=20 >> On Jun 9, 2015, at 5:24 PM, Ben Campbell wrote: >>=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-oauth-introspection-09: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I concur with Alissa's discuss. =20 >>=20 >> Additional comments: >>=20 >> -- There is no reference to RFC 2119, but there seems to be lots of >> capitalized 2119 keywords. If those are intended to have the 2119 >> meaning, please add the usual reference. (I assume that these are >> intended as 2119 keywords for the remainder of the review.) >>=20 >=20 > This seems to be a bug in the xml2rfc template, I=E2=80=99ll fix that.=20= >=20 >> -- 2.1, first paragraph: >>=20 >> If the server MAY support GET, how does a client know to use it? = Would >> you expect them to try and fail? >=20 > Was brought on by Barry Lieba, my suggested fix is to say server MUST = support POST, and remain silent on other verbs. Will that suffice? >=20 >>=20 >> -- 3 >>=20 >> Is there a reason not to use a more standard IANA procedure? (I.e. = let >> people request registrations to IANA, and have them forward the = requests >> to the DE?) >>=20 >> --3.1, under "Name" >>=20 >> The MUST seems unnecessary, as that's the whole point of a registry. >=20 > I pulled the IANA language from other specs, I=E2=80=99ll defer the = proper wording and structure of this to other experts. >=20 >>=20 >> -- 4: >> The security considerations have a lot of restated 2119 keywords. If = you >> want to reinforce those here, it would be better to do so with >> descriptive language, rather than having multiple occurrences of the = same >> normative language. Redundant normative language is error prone, >> especially for future updates. >=20 > Noted. We=E2=80=99re not trying to re-state normative requirements in = multiple locations, so I=E2=80=99ll carefully read through this again to = make sure we=E2=80=99re saying something new where we add another 2119 = statement. >=20 >>=20 >> -- 4, bullet list: >>=20 >>=20 >> It seems odd to have 2119 keywords in a "For instance" section. >=20 > This was at the request of WG members and I=E2=80=99m open to wording = it better. People wanted the protected resources to be able to count on = count on the AS doing at least some reasonable checks on the token=E2=80=99= s state. We can't prescribe exact AS behavior because the nature of = tokens is going to vary so wildly (some expire, some don=E2=80=99t). = What we want to do is provide a set of common checks that servers need = to do in the right circumstances, depending on the nature of their = tokens.=20 >=20 >>=20 >> --4, 6th paragraph from end >>=20 >> The reference to [TLS.BCP] should probably be normative. >=20 > It=E2=80=99s a best current practice on deployment practice of a = supporting protocol, I think informative is the right level here but = I=E2=80=99ll defer to other expertise if there=E2=80=99s a better form. >=20 >>=20 >> -- 4, last two paragraphs:=20 >>=20 >> "An authorization server offering token introspection MUST be able to >> understand the token values being presented to it during this call." = and >> "the authorization server MUST be able to decrypt and validate the = token >> in order to access this information." >>=20 >> These seem more like statements of fact than normative language. >=20 > This is a fair characterization of this section, we can change those = to =E2=80=9Cneeds to=E2=80=9D or lowercase =E2=80=9Cmust=E2=80=9D. >=20 > =E2=80=94 Justin >=20 >=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_7BF79A10-DBF3-41DB-ABA5-CC353331B850 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ben,

I=E2=80=99ve uploaded a new draft that should address your = comments below:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10

Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspe= ction-10.txt

Please let me know if you have any further = questions,
 =E2=80=94 Justin

On Jun 11, 2015, at 6:25 PM, Justin Richer <jricher@MIT.EDU> = wrote:

Ben, = thanks for your review. Comments inline.

On Jun 9, 2015, at 5:24 = PM, Ben Campbell <ben@nostrum.com> wrote:

Ben= Campbell has entered the following ballot position for
draft-ietf-oauth-introspection-09: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-introspection= /



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I concur with Alissa's discuss. =  

Additional comments:
-- There is no reference to RFC 2119, but there seems to be = lots of
capitalized 2119 keywords. If those are intended = to have the 2119
meaning, please add the usual reference. = (I assume that these are
intended as 2119 keywords for the = remainder of the review.)


This seems to be a bug in the xml2rfc template, I=E2=80=99ll = fix that.

-- 2.1, first paragraph:

If the = server MAY support GET, how does a client know to use it? Would
you expect them to try and fail?
Was brought on by Barry Lieba, my suggested fix is to say = server MUST support POST, and remain silent on other verbs. Will that = suffice?


-- 3

Is there a = reason not to use a more standard IANA procedure? (I.e. let
people request registrations to IANA, and have them forward = the requests
to the DE?)

--3.1,= under "Name"

The MUST seems unnecessary, = as that's the whole point of a registry.

I pulled the IANA language from other specs, I=E2=80=99ll = defer the proper wording and structure of this to other experts.


-- 4:
The security considerations have a lot of = restated 2119 keywords. If you
want to reinforce those = here, it would be better to do so with
descriptive = language, rather than having multiple occurrences of the same
normative language.  Redundant normative language is = error prone,
especially for future updates.

Noted. We=E2=80=99re not trying = to re-state normative requirements in multiple locations, so I=E2=80=99ll = carefully read through this again to make sure we=E2=80=99re saying = something new where we add another 2119 statement.


-- 4, = bullet list:


It seems odd to = have 2119 keywords in a "For instance" section.

This was at the request of WG = members and I=E2=80=99m open to wording it better. People wanted the = protected resources to be able to count on count on the AS doing at = least some reasonable checks on the token=E2=80=99s state. We can't = prescribe exact AS behavior because the nature of tokens is going to = vary so wildly (some expire, some don=E2=80=99t). What we want to do is = provide a set of common checks that servers need to do in the right = circumstances, depending on the nature of their tokens.

--4, 6th = paragraph from end

The reference to = [TLS.BCP] should probably be normative.

It=E2=80=99s a best current practice on deployment practice = of a supporting protocol, I think informative is the right level here = but I=E2=80=99ll defer to other expertise if there=E2=80=99s a better = form.


-- 4, last two paragraphs:

"An authorization server offering token introspection MUST be = able to
understand the token values being presented to it = during this call." and
"the authorization server MUST be = able to decrypt and validate the token
in order to access = this information."

These seem more like = statements of fact than normative language.
This is a fair characterization of this section, we can = change those to =E2=80=9Cneeds to=E2=80=9D or lowercase =E2=80=9Cmust=E2=80= =9D.

=E2=80=94 Justin




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail=_7BF79A10-DBF3-41DB-ABA5-CC353331B850-- From nobody Mon Jun 22 20:13:54 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7779B1B3271 for ; Mon, 22 Jun 2015 20:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 sTHB5jmsbjKs for ; Mon, 22 Jun 2015 20:13:52 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 BC1FF1B3270 for ; Mon, 22 Jun 2015 20:13:52 -0700 (PDT) Received: by obctg8 with SMTP id tg8so126022296obc.3 for ; Mon, 22 Jun 2015 20:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qM89SEmiEHLOpcdyOj1tC3a10UDQzg04BZtxocjPpoA=; b=IT5Kup4QtF4XS5H46wREFNnS/E4FQ5/u0Cy2+GqKZH8L7mSho0zxZF/VyTJOlTS4bO a5uAIAJAOHlYjwibRwzX5OewCM8gHRFn2F8fPIpSttqy5/whI27fJiUqWlTdrNwyrHsH PvMJ0ZI5LT1L2ExfrCfPDyApfNOzVtbnjCWTwu9aLSCwHcEGIcKzsm/wB4Y1B5sE8eyh 1MEWjfStp0M5wed49eAZYPPLrRLyoIRmq+WocqQor1FCK0AgpALFll8s+RC+WbYqZ16V 9SKNAE2Nhh9XEc6jouEQxGvmhbF8ztOjx6p13BeSvzSLaPrwSTRlw3MYJqvl9Zz1aNlD lnDw== MIME-Version: 1.0 X-Received: by 10.60.130.167 with SMTP id of7mr27818717oeb.85.1435029232044; Mon, 22 Jun 2015 20:13:52 -0700 (PDT) Received: by 10.202.84.73 with HTTP; Mon, 22 Jun 2015 20:13:51 -0700 (PDT) Date: Mon, 22 Jun 2015 21:13:51 -0600 Message-ID: From: "I.Valdez" To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=089e013a11169e4f83051926c780 Archived-At: Subject: [OAUTH-WG] Oauth mailing list X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 03:13:53 -0000 --089e013a11169e4f83051926c780 Content-Type: text/plain; charset=UTF-8 --089e013a11169e4f83051926c780 Content-Type: text/html; charset=UTF-8 --089e013a11169e4f83051926c780-- From nobody Wed Jun 24 08:20:13 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCA71A00DB for ; Wed, 24 Jun 2015 08:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 23UCKbXcwtVL for ; Wed, 24 Jun 2015 08:20:11 -0700 (PDT) Received: from mx0b-0019e102.pphosted.com (mx0b-0019e102.pphosted.com [67.231.157.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE7B1A8ADA for ; Wed, 24 Jun 2015 08:20:11 -0700 (PDT) Received: from pps.filterd (m0074414.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.14.7/8.14.7) with SMTP id t5OFGJvr009032 for ; Wed, 24 Jun 2015 10:20:10 -0500 Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by mx0b-0019e102.pphosted.com with ESMTP id 1v7x9m03fd-1 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 24 Jun 2015 10:20:10 -0500 Received: by ykdy1 with SMTP id y1so25521701ykd.2 for ; Wed, 24 Jun 2015 08:20:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GL9S+BZhywS4eOewP7Uyy9R+Ez9mKh/W04l9l0EyB4c=; b=mzKgnwMdMenDlX04ULgkjbQvQG899wCCPNkHDzdRtB+Y6lY2xO62NFNqLLBnmHPgtx 7yAOETgb2s9LFWD0llqXdOkX+AsiW3uzT3E1L62hmbk9QMl66rA8xylSX1iuI2JlYjWK Qcnp3/vYkJhDRCMC8KFWdmVhYebZ6OQKL3dt7ooftxFu2kwlrJJ6XXIRyDAXLtgtdnWp oTUHHSKzJepFicy3y2oAtqvXzE7fPn1mGuzS7tKmkDj3VNlKdA2W5FXE6nrN35YC6NsJ skWC9Bfm2ieLNna0hz87bgfi5C26zqgLXbBEIXpOGWxfTUHkkVuv7TzetK1YDK2ICS9x UWIg== X-Gm-Message-State: ALoCoQkdwhOvLtPkmAUQhkuZl47cSy5l6S4SDJsAfZ3gjO/UI0misVi6FRIRtEPamVtB/XrvJNDqssKiZCdp/Ll8z+Q8EuoFpg1zR4zTOIJy5hIqicxoJcixRJUaVCFjQpF15PqBradT X-Received: by 10.13.193.198 with SMTP id c189mr46577000ywd.122.1435159209866; Wed, 24 Jun 2015 08:20:09 -0700 (PDT) X-Received: by 10.13.193.198 with SMTP id c189mr46576993ywd.122.1435159209802; Wed, 24 Jun 2015 08:20:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.70 with HTTP; Wed, 24 Jun 2015 08:19:50 -0700 (PDT) From: Adam Lewis Date: Wed, 24 Jun 2015 10:19:50 -0500 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a114e837ae58ef10519450a64 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=1.11022302462516e-15 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.664759139856529 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.664759139856529 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.664759139856529 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1506240250 Archived-At: Subject: [OAUTH-WG] Motivation for plain transform method in PKCE, and encrypted code_challenge in code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 15:20:12 -0000 --001a114e837ae58ef10519450a64 Content-Type: text/plain; charset=UTF-8 Hi, I'm probably missing something here, but what is the use case for allowing the plain transform method in PKCE? It seems to me the entire point of sending the hash of the code_verifier (code_challenge) rather than the code_verifier itself is to avoid leaking the code_verifier through the browser during the authorization request. It seems using the plain type would enable an attacker to intercept the code verifier and use it to exchange the code for the AT. If a client is really unable to compute a S256 hash, wouldn't it just fall back to vanilla OAuth? Also, under security considerations, it mentions that if the code challenge is returned as part of the code, it needs to be encrypted. Not sure why since it was sent un-encrypted, where the attacker would have already had the opportunity to intercept/obtain it. Plus 7.3 re-enforces the point that the code verifier has sufficient entropy to prevent brute force attacks. I suppose the motivation then for encrypting the code_challenge is to address the scenario whereby 1) the plain transform method is used, and 2) a malicious app fails to intercept the code_challenge, but then 3) gets the code? Just looking for some background understanding of what went into these designs. tx! adam --001a114e837ae58ef10519450a64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'm probably missing something = here, but what is the use case for allowing the plain transform method in P= KCE?=C2=A0 It seems to me the entire point of sending the hash of the code_= verifier (code_challenge) rather than the code_verifier itself is to avoid = leaking the=C2=A0code_verifier=C2=A0through the=C2=A0browser during the aut= horization request.=C2=A0 It seems using the plain type would enable an att= acker to intercept the=C2=A0code verifier=C2=A0and use it to exchange the c= ode for the AT.=C2=A0 If a client is really unable to compute a S256 hash, = wouldn't it just fall back to vanilla OAuth?

Also, u= nder security considerations, it mentions that if the code challenge is ret= urned as part of the code, it needs to be encrypted. Not sure why since it = was sent un-encrypted, where the attacker would have already had the opport= unity to intercept/obtain it. Plus 7.3 re-enforces the point that the code = verifier has sufficient entropy to prevent brute force attacks.=C2=A0 I sup= pose the motivation then for encrypting the code_challenge is to address th= e scenario whereby 1) the plain transform method is used, and 2) a maliciou= s app fails to intercept the code_challenge, but then 3) gets the code?

Just looking for some background understanding of wha= t went into these designs.


tx!
a= dam



--001a114e837ae58ef10519450a64-- From nobody Wed Jun 24 12:18:36 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945151B2CEC for ; Wed, 24 Jun 2015 12:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ZeCfBPTV3wG1 for ; Wed, 24 Jun 2015 12:18:32 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0073.outbound.protection.outlook.com [65.55.169.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA281B2CEB for ; Wed, 24 Jun 2015 12:18:32 -0700 (PDT) Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1029.namprd02.prod.outlook.com (10.161.203.147) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 24 Jun 2015 19:18:30 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0201.000; Wed, 24 Jun 2015 19:18:30 +0000 From: Antonio Sanso To: OAuth WG Thread-Topic: Same Origin Method Execution (SOME) Thread-Index: AQHQrrKNUGqwK9xwKk+RnZEBcYFkaQ== Date: Wed, 24 Jun 2015 19:18:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2a02:1205:5057:bb70:f443:7dd6:ebb:c57] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1029; 5:jc0NRzt8cyiuI7zThfZDcCqsMSkq1vY1P3ls1CgdAC/D3CDF0CjbZ34wxAd3eu7kcaYVZoKfjXELow9SvWAmjsMerA2UhsqeH5zin1F2MHa2aL6Uh2ewDpdTb6J0SQRYacAcqdz2ljbPxb1P//lDeQ==; 24:Mck85iC9hVcnaznKQtFfWm4AgHlfXX/rLncPfMlHaeSR2PRiwabtHRssGGGIi5VuAKrAkFG0ArO0JU3KnLfz6hLEgf/zOAEQc/HCTIcoI2A=; 20:ctd9XgVs1fd81c+PKUi4Xz94Wee02afhdn2KXUZXpXIiasf9WwwQ/ZWFgdxkmRqYL9du5OugVE0Ow73oDh2HMQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1029; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0201MB1029; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1029; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(19580395003)(46102003)(87936001)(2656002)(122556002)(40100003)(82746002)(92566002)(229853001)(83716003)(62966003)(86362001)(33656002)(99286002)(106116001)(54356999)(50986999)(107886002)(5001960100002)(2900100001)(110136002)(77156002)(5002640100001)(450100001)(189998001)(36756003)(77096005)(102836002)(15975445007)(1600100001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1029; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <00D1248FE2503742A589B4EA02210F9C@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2015 19:18:29.5218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1029 Archived-At: Subject: [OAUTH-WG] Same Origin Method Execution (SOME) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 19:18:34 -0000 hi *, just sharing. Not directly related to OAuth per se but it exploits several OAuth client e= ndpoints due to some common developers pattern http://www.benhayak.com/2015= /06/same-origin-method-execution-some.html (concrete example in http://www.= benhayak.com/2015/05/stealing-private-photo-albums-from-Google.html) regards antonio= From nobody Wed Jun 24 14:03:16 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25F61B2E12 for ; Wed, 24 Jun 2015 14:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 zq_t7gDzZ1tA for ; Wed, 24 Jun 2015 14:03:14 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 0301F1B2E25 for ; Wed, 24 Jun 2015 14:03:14 -0700 (PDT) Received: by qkfe185 with SMTP id e185so28502767qkf.3 for ; Wed, 24 Jun 2015 14:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RTGq7yuG+ov7NqP/Dp8HJ8dM1Pi1tLt/iLtDf4vpoHE=; b=DTOVLkcEJoO1mJEg5Tf61ygXAttZBeZQi9mdT5PSCCAXNbolWGGxadKzgnwMR69aah Pu30+3TlSKPqnilQrPDnU5sES/Sfgsw4ex1bq0bdLB1Qkw/5GkBvTYOxq20ht14MYu1/ EgyIVodJdrnBL2TSgA5cFN8WfdvqfZMewV4lRXuFveaHmEXlz0yYxlQq6yTgeZUbY1xc 3xGq9Z+9Hj57tukm2Ngq9JyJRbTwPpscN1oRZamV8QpCiBsJpCzFDFoymiNZZWoQFOBG 8YopdkjmNl9DQFJLnuyQkTbfw5XdpEHf4o+IQCuYOm7Sma0mf5Dz+5X5ZhLtqrVeQx3n 9Tzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RTGq7yuG+ov7NqP/Dp8HJ8dM1Pi1tLt/iLtDf4vpoHE=; b=OtgWAhgwL0Ae/pHTRZ37QBm+JTjoEYbadPogn6+xlqvxwklZgvgvvYdHwA2f085l2a 8nPeF/qlferN3Cap6G0fm6XD9MYcDXh4I0NNCmIFUy5hpjfmbunFa1j/pzHH2foljLwx kIp+NlHLKJZwZUfpPeF9lE8tBuJBZj8LR058MWZZERkao5wqOXfU11EypaCMq/dhq53Y I4MQfOWr+lNq035vTgo1EJ6XzVmJ7U6Obilb256CzJGB8zbK00+fFZdUWyji0DdtshiZ MYeX9vMxDHeaCwUEpDvDzu+A2FvF7UXb+q2jny/bck4hYMJwf1bU/Su7TxhtssusI0q8 g4VQ== X-Gm-Message-State: ALoCoQkwHY6+7CsDAHtIKnKw+h9EpEQSpodXcwBl4aafqPRlz/7kLtkZ2jVjs44XXAObzIJQ1ZeL X-Received: by 10.55.21.211 with SMTP id 80mr88617529qkv.11.1435179793210; Wed, 24 Jun 2015 14:03:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.98 with HTTP; Wed, 24 Jun 2015 14:02:53 -0700 (PDT) In-Reply-To: References: From: William Denniss Date: Wed, 24 Jun 2015 14:02:53 -0700 Message-ID: To: Adam Lewis Content-Type: multipart/alternative; boundary=001a11473dcec39264051949d594 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Motivation for plain transform method in PKCE, and encrypted code_challenge in code X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 21:03:16 -0000 --001a11473dcec39264051949d594 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Adam, I work with Naveen (one of the co-authors), and we support the plain transform method with PKCE for OAuth on iOS currently. My comments are inline: On Wed, Jun 24, 2015 at 8:20 AM Adam Lewis wrote: > Hi, > > I'm probably missing something here, but what is the use case for allowin= g > the plain transform method in PKCE? It seems to me the entire point of > sending the hash of the code_verifier (code_challenge) rather than the > code_verifier itself is to avoid leaking the code_verifier through > the browser during the authorization request. > > It seems using the plain type would enable an attacker to intercept > the code verifier and use it to exchange the code for the AT. > PKCE w/ plain protects against a specific attack where a rogue app intercepts (or eavesdrops) the Authorization Code Grant, but not the initial auth request. The code interception attack vector is quite real on mobile platforms that rely on custom URI schemes for returning the OAuth code to the native app, and was the motivation of this spec. PKCE w/ S256 additionally protects against the case where both the auth request and code grant can be eavesdropped (and potentially the code grant =E2=80=93 but not the initial auth request =E2=80=93 intercepted). Due to = the fact inter-process communication tends to be less secure than HTTPS, this is the best practice. If the rogue app can intercept the initial auth request (which is a risk for a native OAuth token agent), then they are executing a local MitM attack and all bets are off (that attack isn't protected by PKCE, though we are looking at addressing this issue separately, within the OIDF NAPPS Working Group). Importantly, on iOS if your auth request is initiated with a "https://" url (i.e. a normal OAuth2 web request), the auth request can *not* be intercepted by a rogue app, but the returning authorization code grant *can* be (if uses a custom URI scheme to return the code to the native app from the browser). PKCE w/ plain was designed specifically to protect against that attack, and is why we implemented it. > If a client is really unable to compute a S256 hash, wouldn't it just fal= l > back to vanilla OAuth? > PKCE w/ plain prevents some actual attack scenarios today. S256 remains the best practice, but it doesn't invalidate the effectiveness of "plain" in some situations. > Also, under security considerations, it mentions that if the code > challenge is returned as part of the code, it needs to be encrypted. Not > sure why since it was sent un-encrypted, where the attacker would have > already had the opportunity to intercept/obtain it. Plus 7.3 re-enforces > the point that the code verifier has sufficient entropy to prevent brute > force attacks. I suppose the motivation then for encrypting the > code_challenge is to address the scenario whereby 1) the plain transform > method is used, and 2) a malicious app fails to intercept the > code_challenge, but then 3) gets the code? > There are two common ways the Authorization Server can associate the verifier with the code to compare later when the code is redeemed on the token endpoint. One is storing and associating the code and verifier server side, the other avoids server storage by using symmetric encryption to encode both the verifier and code together, and return that as the code (this works as the client treats the authorization code as an opaque blob). Then when the code is redeemed, the server can decrypt, and get the verifier. But that is unrelated to the transform method. > Just looking for some background understanding of what went into these > designs. > I hope the above explanations help. Best, William --001a11473dcec39264051949d594 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adam,

I work with Naveen (one of the= co-authors), and we support the plain transform method with PKCE for OAuth= on iOS currently. My comments are inline:

On Wed, Jun 24, 2015 at 8:20 AM Adam L= ewis <adam.lewis@motorolasolutions.com> wrote:
Hi,

I'm probably missing somethi= ng here, but what is the use case for allowing the plain transform method i= n PKCE?=C2=A0 It seems to me the entire point of sending the hash of the co= de_verifier (code_challenge) rather than the code_verifier itself is to avo= id leaking the=C2=A0code_verifier=C2=A0through the=C2=A0browser during the = authorization request.=C2=A0
=C2=A0
It seems using the plain type would enabl= e an attacker to intercept the=C2=A0code verifier=C2=A0and use it to exchan= ge the code for the AT.=C2=A0

= PKCE w/ plain protects against a specific attack where a rogue app intercep= ts (or eavesdrops) the Authorization Code Grant, but not the initial auth r= equest.=C2=A0 The code interception attack vector is quite real on mobile p= latforms that rely on custom URI schemes for returning the OAuth code to th= e native app, and was the motivation of this spec.

PKCE w/ S256 additionally protects against the case where both the auth re= quest and code grant can be eavesdropped (and potentially the code grant = =E2=80=93 but not the initial auth request =E2=80=93 intercepted).=C2=A0 Du= e to the fact inter-process communication tends to be less secure than HTTP= S, this is the best practice.

If the rogue app can= intercept the initial auth request (which is a risk for a native OAuth tok= en agent), then they are executing a local MitM attack and all bets are off= (that attack isn't protected by PKCE, though we are looking at address= ing this issue separately, within the OIDF NAPPS Working Group).
=
Importantly, on iOS if your auth request is initiated with a= "https://" url (i.e. a normal OAuth2 web request), the auth requ= est can *not* be intercepted by a rogue app, but the returning authorizatio= n code grant *can* be (if uses a custom URI scheme to return the code to th= e native app from the browser). PKCE w/ plain was designed specifically to = protect against that attack, and is why we implemented it.
=C2=A0=
If a client is really unable t= o compute a S256 hash, wouldn't it just fall back to vanilla OAuth?

PKCE w/ plain prevents some actual= attack scenarios today. S256 remains the best practice, but it doesn't= invalidate the effectiveness of "plain" in some situations.
=C2=A0
Also, under s= ecurity considerations, it mentions that if the code challenge is returned = as part of the code, it needs to be encrypted. Not sure why since it was se= nt un-encrypted, where the attacker would have already had the opportunity = to intercept/obtain it. Plus 7.3 re-enforces the point that the code verifi= er has sufficient entropy to prevent brute force attacks.=C2=A0 I suppose t= he motivation then for encrypting the code_challenge is to address the scen= ario whereby 1) the plain transform method is used, and 2) a malicious app = fails to intercept the code_challenge, but then 3) gets the code?

There are two common ways the Auth= orization Server can associate the verifier with the code to compare later = when the code is redeemed on the token endpoint. One is storing and associa= ting the code and verifier server side, the other avoids server storage by = using symmetric encryption to encode both the verifier and code together, a= nd return that as the code (this works as the client treats the authorizati= on code as an opaque blob). Then when the code is redeemed, the server can = decrypt, and get the verifier.=C2=A0 But that is unrelated to the transform= method.

=C2=A0
Just looking for some background understanding of= what went into these designs.
=C2=A0

I hope the above explanations help.

Best,
William

--001a11473dcec39264051949d594-- From nobody Wed Jun 24 16:42:46 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A031ACC88 for ; Wed, 24 Jun 2015 16:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 SD6HwkLCOFcq for ; Wed, 24 Jun 2015 16:42:43 -0700 (PDT) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) (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 EC9A01AC443 for ; Wed, 24 Jun 2015 16:42:42 -0700 (PDT) Received: by qkeo142 with SMTP id o142so30233410qke.1 for ; Wed, 24 Jun 2015 16:42:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zA4Sk+zGrKD1bdlvxJhvRPcb3y8QXRfTYfW69bxIfH4=; b=dWcHRUp0sH4XItWQkUbupvoRU49m5RU3invj5WQ07nFkO32wbpTPSI8wcXQnl3tkr2 fZRzX7Cvn9P9CwRq3P/k/MmboAYtiu/poZCTsnSOF+D91CkbJAeT3I0Xqh5KdqPuK17T 2cRMH1uftKt4Sw28eKkznFZ033/v8bC93A/SNnkjNOLJBGn1s1GdnrIi4iV07J8i1PYA e4r9g3dhi94AwrYBNJBdTfy4IbNtE9UzAUz4uER6//AwSeXWv0TeR0k7dBOLnkhVvj8k 9JSCeG20NL4gJLgu63XOVwQcgG9QTIOwEoMTgmQnNXJdOP2eLU8mFoPbE4Z5ST4ceZ+h Hx2w== X-Gm-Message-State: ALoCoQmvFhdUuPJO5lB+3QX1azWO+ieT4m/45I5Do53iV08Q4YHFFVCp6FY6Lc59n/KgYlGSk6PM X-Received: by 10.140.232.131 with SMTP id d125mr58851377qhc.80.1435189362130; Wed, 24 Jun 2015 16:42:42 -0700 (PDT) Received: from [192.168.1.216] (186-106-160-160.baf.movistar.cl. [186.106.160.160]) by mx.google.com with ESMTPSA id 131sm3971917qhf.14.2015.06.24.16.42.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jun 2015 16:42:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: Date: Wed, 24 Jun 2015 20:42:36 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Antonio Sanso X-Mailer: Apple Mail (2.2098) Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 23:42:45 -0000 Thanks for the info, As I read it, this is an attack on Java Script callbacks.=20 The information tying it to OAuth is not clear. Is the issue relating to JS people using the implicit flow and the JS = loaded from the client somehow being vulnerable? Or is this happening in the JS after authorization in calls to other = resources from the same origin, and it is just coincidence that people = are using OAuth. Understanding if there is any Oauth specific advice to give would be = helpful. I see there are ways to prevent the SOME exploit. Regards John B. > On Jun 24, 2015, at 4:18 PM, Antonio Sanso wrote: >=20 > hi *, just sharing. >=20 > Not directly related to OAuth per se but it exploits several OAuth = client endpoints due to some common developers pattern = http://www.benhayak.com/2015/06/same-origin-method-execution-some.html = (concrete example in = http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.= html) >=20 > regards >=20 > antonio > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jun 25 03:48:33 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EAC1B352A for ; Thu, 25 Jun 2015 03:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.254 X-Spam-Level: *** X-Spam-Status: No, score=3.254 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 vTthABxIa3uO for ; Thu, 25 Jun 2015 03:48:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0075.outbound.protection.outlook.com [207.46.100.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A6B1B352B for ; Thu, 25 Jun 2015 03:48:30 -0700 (PDT) Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1032.namprd02.prod.outlook.com (10.161.203.15) with Microsoft SMTP Server (TLS) id 15.1.201.16; Thu, 25 Jun 2015 10:48:27 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0201.000; Thu, 25 Jun 2015 10:48:27 +0000 From: Antonio Sanso To: John Bradley Thread-Topic: [OAUTH-WG] Same Origin Method Execution (SOME) Thread-Index: AQHQrtd3Tpnpu59uf06O0m3GZFMlH529D7iA Date: Thu, 25 Jun 2015 10:48:27 +0000 Message-ID: <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [62.2.175.26] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1032; 5:VQoNtcmtk9JPCQC9+lJY61oKmS237i3m5ELEsL6aSHcF55tQU7R1bIepsrx2IvgGAcxSiZvTObpP97ijNAiNmeRm9zZEsH+QuKHWtA0pvLddKMKIKf2LgKzvqYpHuz1/G3CaFPLiCmYht934HEIWlw==; 24:lkcRZo/VHQmcmn507hTrAAsqmvAaL3WgeTh0CllG2GiJIxUusO8izIBjk6h+sSUGky6+9fNf6wtWgTfHPWnO+0AeT4Cvj4SVBmNo9fkiDq8=; 20:4A5SW50ho7O7DNNhq2JawWdUPE/Lo39FSIy7+UskhjYw2c7A+UTusX9GrVvoVj/F/P6GMMypmUbJtNZnBQz97g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1032; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0201MB1032; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1032; x-forefront-prvs: 0618E4E7E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(243025005)(377454003)(24454002)(51914003)(46102003)(19617315012)(99286002)(106116001)(16236675004)(50986999)(5001920100001)(76176999)(54356999)(77096005)(1600100001)(102836002)(15975445007)(66066001)(83716003)(189998001)(92566002)(36756003)(87936001)(5001960100002)(2950100001)(2900100001)(62966003)(77156002)(2656002)(5002640100001)(122556002)(40100003)(82746002)(33656002)(19580395003)(19580405001)(110136002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1032; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_51B1A21C4893403EAE0033F4B7827346adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2015 10:48:27.0767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1032 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 10:48:32 -0000 --_000_51B1A21C4893403EAE0033F4B7827346adobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi John On Jun 25, 2015, at 1:42 AM, John Bradley > wrote: Thanks for the info, As I read it, this is an attack on Java Script callbacks. The information tying it to OAuth is not clear. Is the issue relating to JS people using the implicit flow and the JS loade= d from the client somehow being vulnerable? Or is this happening in the JS after authorization in calls to other resour= ces from the same origin, and it is just coincidence that people are using = OAuth. is more the second one :) Extrapolating from the white paper [0] "The most common technique tasked with ful=1Clling the above described need is OAuth. In order to gain access to third-party r= esources using OAuth, the service shall utilize a third-party endpoint (OAuth dialog= ) that will ask for the resource owner's approval. The problem with this process is tha= t redirecting the service to an OAuth dialog means losing the content of the currently op= en service document. For overcoming this problem, developers open a pop-up window to d= isplay the dialog in a singular browsing context. Once the user permits or denies = access to the service, the OAuth dialog pop-up will be redirected to render a callbac= k endpoint hosted on the service domain. This document should eventually notify the se= rvice that the process has been completed. For the new pop-up window to notify the service window upon approval, denia= l or for it to transfer access tokens or similar data, developers may implement call= back endpoints that use a script referencing the "opener" window for executing a callback = method of the service. When developers also opted for providing the service with the deci= sion on how to "call it back" through a callback parameter, the entire domain becomes v= ulnerable to SOME." regards antonio [0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf Understanding if there is any Oauth specific advice to give would be helpfu= l. I see there are ways to prevent the SOME exploit. Regards John B. On Jun 24, 2015, at 4:18 PM, Antonio Sanso > wrote: hi *, just sharing. Not directly related to OAuth per se but it exploits several OAuth client e= ndpoints due to some common developers pattern http://www.benhayak.com/2015= /06/same-origin-method-execution-some.html (concrete example in http://www.= benhayak.com/2015/05/stealing-private-photo-albums-from-Google.html) regards antonio _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_51B1A21C4893403EAE0033F4B7827346adobecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <04BB03644B25EA4A9F0ACDC442FF7A23@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable hi John

On Jun 25, 2015, at 1:42 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks for the info,

As I read it, this is an attack on Java Script callbacks.

The information tying it to OAuth is not clear.

Is the issue relating to JS people using the implicit flow and the JS loade= d from the client somehow being vulnerable?

Or is this happening in the JS after authorization in calls to other resour= ces from the same origin, and it is just coincidence that people are using = OAuth.

is more the second one :) Extrapolating from the white paper [0]

"The most common technique tasked with fullling
the above described need is OAuth. In order to gain access to third-pa= rty resources
using OAuth, the service shall utilize a third-party endpoint (OAuth d= ialog) that will
ask for the resource owner's approval. The problem with this process i= s that redirecting
the service to an OAuth dialog means losing the content of the current= ly open service
document. For overcoming this problem, developers open a pop-up window= to display
the dialog in a singular browsing context. Once the user permits or de= nies access to
the service, the OAuth dialog pop-up will be redirected to render a ca= llback endpoint
hosted on the service domain. This document should eventually notify t= he service that
the process has been completed.
For the new pop-up window to notify the service window upon approval, = denial or for
it to transfer access tokens or similar data, developers may implement= callback endpoints
that use a script referencing the "opener" window for execut= ing a callback method of the
service. When developers also opted for providing the service with the= decision on how
to "call it back" through a callback parameter, the entire d= omain becomes vulnerable to
SOME."

regards

antonio



Understanding if there is any Oauth specific advice to give would be helpfu= l.   I see there are ways to prevent the SOME exploit.

Regards
John B.


On Jun 24, 2015, at 4:18 PM, Antonio Sanso <asanso@adobe.com> wrote:

hi *, just sharing.

Not directly related to OAuth per se but it exploits several OAuth client e= ndpoints due to some common developers pattern http://www.benhayak.com/2015/06/same-origin-method-execution-some.html = (concrete example in http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.h= tml)

regards

antonio
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth


--_000_51B1A21C4893403EAE0033F4B7827346adobecom_-- From vibiswas@cisco.com Thu Jun 25 14:19:45 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0791B2AAA for ; Thu, 25 Jun 2015 14:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.611 X-Spam-Level: X-Spam-Status: No, score=-12.611 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1TJzv5SV97SW for ; Thu, 25 Jun 2015 14:19:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E40F1B2AA8 for ; Thu, 25 Jun 2015 14:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12866; q=dns/txt; s=iport; t=1435267184; x=1436476784; h=from:to:subject:date:message-id:mime-version; bh=2fsZPz12B3J3YK2YZQ6EWIQVMB6ZHVh5vBXV1RTiXoY=; b=NaucmckjmzbD8oGQaC2t0+lxRGOijMlAGItBKXG0HMXY091JOtaOBpba GFUefttr9aDXCnhBjYumqrcQXbgHqxYbKQQF2ylBZ6zw15symZDzPmH+r 4FwlTT6SYCC6rCRZGNoyI4b9B/4FRPbkfw+1jZIk++7ul+RH8YSl/HpAh Q=; X-Files: image003.jpg : 5264 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AGCABvb4xV/5NdJa1ZA4JFTFRfAQW8KDyCHXeEfQKBQDwQAQEBAQEBAYEKhCQBBAUgCAFZBAEPFgEBAQIIHgUQAQMEBwwmAQQSAQYCBoghDadtpjkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIZViUYWCyiDBoEUBZQGAQeDbAFjiHaDVZJoERVjgxdvAQEBgUOBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,679,1427760000"; d="jpg'145?scan'145,208,217,145";a="10383869" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jun 2015 21:19:43 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t5PLJhBt015166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 25 Jun 2015 21:19:43 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.112]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 16:19:43 -0500 From: "Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco)" To: "OAuth@ietf.org" Thread-Topic: JWT Token on-behalf of Use case Thread-Index: AdCvjKZzog4lHzdSReisaGHaz/hQ6g== Date: Thu, 25 Jun 2015 21:19:42 +0000 Message-ID: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.242.89] Content-Type: multipart/related; boundary="_004_6B22D19DBF96664DBF49BC7B326402B42739A904xmbalnx09ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 21:20:27 -0000 --_004_6B22D19DBF96664DBF49BC7B326402B42739A904xmbalnx09ciscoc_ Content-Type: multipart/alternative; boundary="_000_6B22D19DBF96664DBF49BC7B326402B42739A904xmbalnx09ciscoc_" --_000_6B22D19DBF96664DBF49BC7B326402B42739A904xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which = denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a c= ustomer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, [CISSP] Cisco Systems, Inc Bldg. J, San Jose, USA, Phone: +1 408 527 9176 --_000_6B22D19DBF96664DBF49BC7B326402B42739A904xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

  I am looking to solve a use-case similar to W= S-Security On-Behalf-Of with OAuth JWT Token.

 

  Is there a standard claim which we can define= within the OAuth JWT which denote the On-behalf-of User.

 

For e.g., a Customer Representative trying to create= token on behalf of a customer and trying to execute services specific for = that specific customer.

Regards,

Vivek Biswas,
3D"CISSP"

 

Cisco Systems, Inc

Bldg. J, San Jose, USA,

Phone: +1 408 527 9176

 

--_000_6B22D19DBF96664DBF49BC7B326402B42739A904xmbalnx09ciscoc_-- --_004_6B22D19DBF96664DBF49BC7B326402B42739A904xmbalnx09ciscoc_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=5264; creation-date="Thu, 25 Jun 2015 21:19:42 GMT"; modification-date="Thu, 25 Jun 2015 21:19:42 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAkACQAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCABuAV0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0rWvF ul6E3l3c+6YjPlpy34+lY3/C0dI/543P5CvLLq5lvLqS5uHLyytuZj3NRUHlSxs2/d2PWP8AhaOk f88bn/vkUf8AC0dI/wCeNz/3yK8nopk/Xah6x/wtHSP+eNz/AN8ij/haOkf88bn/AL5FeT0UB9dq HrH/AAtHSP8Anjc/98ij/haOkf8APG5/75FeT0UB9dqHrH/C0dI/543P/fIo/wCFo6R/zxufyFeT 0UB9dqHrH/C0dI/543P/AHyKmtfiVotxKEkMsIPRnXj9K8hooH9dqH0TFKk8SyROrowyGU5BFPrh PhZfSz6VdWsjFkgkHl5PQEZxXd0j0qc+eKkFLRRQaBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfOVFAopnzwUUUUAFFFFABRRRQAUUUUAFFFFA HpHwm/1Go/76/wAq9Erzv4Tf6jUf99f5V6Jmkezhf4SClpKWg6AooooAKKSigBaKKKACiikoAWik ooAWiiigAooooAKKKKACiikoAWiiigAooooAKKKKACiiigAooooA+chRQKKZ88FFFFABRRRQAUUU UAFFFFABRRRQB6R8Jv8AUaj/AL6/yrroNXeXxNdab5YEcMKyB+5JrkvhN/qNR/31/lW7Zf8AJQdQ /wCvZKR61B2pxNnUdXstKRTeTBGc4RACzMfYDmq1l4lsLy6S2BmimkzsSWJl3fQ4xVPSo0ufF2sT z4ee3KRQhv4EKg8fUk1uXcqW9rLcSoGWFS+Mc8DPFB1k9FcLF4p1No4b1T5vmON1mID8qE44b171 pw32t6rfalFZS21vFaT7I2dCS/yg4I/GgDpd67tu4bgMkZ5rPuNesbbT4rySRvLmO2NQp3OfQDr2 rH02K+/4TW/825RtsMe8BOCPQelVorm91W40C8aSFC5clQmcEEg4/CgDqNP1KDUY3aDf+7bawdCp Bxnv9atVy+peJLqyj1ARxo0kd6lrCdpONyA5I74yar23ie6sZ5vtbNeWqwNL5ohMZRl/h+hoA6q8 vIbC1e4uX2RLgFvqQB+pqSWRYYnkkOEQFifQCuN1tNan8Ntd3d3biKRone3WP7ql1wAc9enNdXqf /ILuv+uLfyNAD7S6ivbSK5t23wyqHRvUGi7u4bG1kubmQRwxjLMe1cppV1qT2Gh6fp8kMSSWKySS OuSuMDgVBr9zqFx4fvLW5miMtrdxIZFXAkUsMcdjQB1unalFqcDSwrIqhsfvEKn9auVzouNW1W/u obO4itoLNvKZzHuaSTAJ+g5qq3iHUzHDbRwwG/F2bWXrs6ZDj274oA6ulrlbq516z1Oz0/7XayG6 LHzjEQUA9s80QXHiC4vLuw+02yG0wwuNmTJkZAx296AOppCyrjcQMnAya5f+3bi50i0uZb62sN2U lJQszODj5R6VUkvdQ1fTtKuDPFGxuxGdqHBIB+b/AOtQB1wuo2vGtgT5qIHIxxgkjr+FTVzuo69c aVc3iSok32e0jkUAYLyM5XH04FMuLjXdIhivrye3uYi6i4gRNuwE4yp9vfrQB0tFcrHfa3qM+qvb XFvBBZTMkSmPJkwAfmrf0q8bUNMt7l02NIgLKOx70AXKKKKACiiigAooooAKKKKAPnIUUUUz54KK KKACiiigAooooAKKKKACilpKAPSfhN/qNR/31/lW7Zf8lB1H/r2j/rWF8Jv9RqP++v8AKt2y/wCS hah/17R0j1aP8OJoajojT3wv7C5a0vQuwuBuWRfRh3+tRxaZqs8g/tLUo2g5DQwxACQH1J5qvJf6 rqmrXttpc9vbR2TBGMqb2kYjPTsOetbdo8jW6LcNGblVHmiM8BqDsMe30XVrNVtbbVlWyQ/JuiBk Vc5256e2av6Zpf8AZ1xfS+Zv+1z+djH3flAx+lWZr21t1zPcwxjdty8gHPpz3qpca7Y22oW1o88R e4DYYSLhdoB55754oAhm0i7XXzqFndpGkyqs6OmSQvoaSy8P/Y4tNTz932Ldzj72ST/WtKW9tbeV Y5rmGORvuq8gBP0FOmu7e2UtcTxRKO7uF/nQBk3HhxbgXpNw8ck9ytzE6DmJ1UAfXpSw6VqVyHj1 e/jnt2RozFHEFDgjGSa03v7RPL33UC+b/q8yAb/p60s15bWzKs9xDEz/AHQ7hSfpmgDn5fDmpzWA 059VVrJSu3dEDIVVgQpP4da6G5h+0WssOceYhXPpkUXM4trSacjcI0Z8DvgZrB0i413UYbbUftFn 9luMP9nCHKof9ruaALmm6F/Z8li3nbvstr9n6fe96iv/AA79tivU8/b9pmjlzj7u0g4/StaW9toJ FjmuYY5H+6juAT9AaWe5gtY/MuJo4U6bpHCj8zQBkXGi3kOpT3ek3q2/2kgzxSJuUsBjcPQ4pbXw 2Lb7M5uWkmjna4lkYcyMRj8K14p4plUwyxuGGQVYHI9aXzohn94nB2n5h19KAKV3pf2nV7K98zb9 mDDbj72afBp3k6hd3O/P2gAbcdMCle8WZ42tbu2aJXIl+cHjHQe9RWWu2N9JcJHPEDDIUOZB83AO Rz05oAy4fC9xYy281ndx+dEsiHzY8jDNuyPQihPC94ml/Z/7S3Tx3HnwyGMAKffHrmujZ1TG9guT gZOMmsvxJqFzpumpJZlBM8yRguMgZOOlAED+HWvDcNqVwJHuLVYHMa7cEMWDD8/0pn9hajd+Vb6l qQns4mDbVj2vLjpuP19KVr/U9K1Syg1CWC4t7tzGGRdjI3UcdxWyLu2aYQrcRGVhuCBxuI9cUAU7 DSPsQ1EebuF5M0vT7uRjFWNNs/sFhDbbt3ljG71p8d9azTGGK6geUdUWQFh+FYy6pd6lrdxBY3lr Db2hAcEB2k7nvwBQB0NFQQXlvdbhbXEMxX73luGx9cUkV9azs6w3MMjJ98JICV+vpQBYoqjLepc2 sjafd2rupA3bwyr9cVPPe21pt+03EMO7p5jhc/TNAE9FRNcRIoZ5UVW6MWABpIbu3uIjLBPFJGOr o4IH4igCaiqUuowPY3E1pPDMYkJ+RwwBx3xT9MuXu9Nt55Mb5EDHHSgD58FFAp8UbTTJHGMu7BQP c0z56wzuB3NKQV+8CPqMV314dK8B2sNutnFfatIgd2lGVSqKeOre7Bi1XRbSSEgjdEuGH50G7pRj pKWpx38qUAkZAJA9BXYi1tpPhysoiRWe9278fMFJ9fpWrr2p/wDCIfZLWx0e2ksmjBM0i53nvzQP 2Gl2zzjj1pSCv3gR9Riu58LRafrOt6nqMdghMMXmQ2hAxu+lZ2q+Lv7Q0+8sdQ0i3gnKkRMi4aNs 980E+ySjzNnLY+tFeh3uqReHvCejTw6ZZ3ElwpVzMnoM9qr6ylhf+GtP8QmwS1lWcCWNFwJFB54o KeHSW5wpBHUEd+aSuj8W6zp+rvbnT4guwHcQm3HtXOUGEkk7I9J+E3+o1H/fX+Vbtl/yUHUP+vVK wvhN/qNR/wB9f5V2cWkRxa5PqYkcyTRrGUPQAd6R61BXpxMzV7TSbq6uLhL8WWo2y/PNHJtYcZG4 Hg1lR6nfWVhY66sJllvY/s8yKMb36Rvj8h9DXV3ei6dfTrNd2NvNKvR3jBNVp9PnutdtnkRVsLRC 0YBHzSHjp6AUHUYV5o39nRW9wz2lzNFCzT292R+8J5LKT0PbNTMdOuNS8O3K20MMM0cxxIoH8IwC T1ror3SbHUWRr20gnKfdMiA4pbvS7K+hjiu7WGaOPlFdAQv0oA4iGxk1G61j7ReaYkjTurC6hLOi fwlW3DjHIxWlpumQXGsWUd7ImoGGxAEjD5ZOeu010N1omm3ro11Y28rRjCl4wcD0q0ltDGwZIkVg u0ELggen0oA4zS9FsJ9L1tJIFfyp5EiLcmIAZAU/w8+lRXASK0i1WcWl8Pscfn29wwEigDqh9T+t dwltDGrqkSKJDlwFA3H39aqy6Jps80csthbPJEAEYxjKgdMUATxyxNYrMw2wmIMQw6LjPP4VyV4t npH2W+8O32PtE6j7Gj7o5Qx5wvUV2ZUEYI4xjFU4NE021ujcwWNvHOf+WixgGgDjIrCbULrWBc3m mxzNO6ut3CWkjT+HadwwMdMVdsIrd9bt4NYuIryOKxT7NJKMJKcne2DxnpXTXmjadqEyy3llbzyL 0Z0BNPu9Ksb63WC6tIZYk+6rICF+npQBjQS2Vj4ojSF4YrdrPEW1gEJDEkDt3rnrlodRku1SXfDJ rEalkbqMc4NdtLoemzWcdrJY27W8ZykZjGF+lSx6ZZQoEitIEVWDALGAAR0P1oAxdQ0yysdW0v7L bRxedcYkCjAbCnqKi0zT7C7Os2bpAjSXDIAoAYDaOneuleGORkaRFZkOVJHKn1FU7nToIpZr+0so G1EoQsmAGY/WgDA0b7Vq+qR298GMejEo7HpNL0Vvy5+tXPGyCXRoUZioa5jGQcEc1paHpx0zTUhk bdOxMkz/AN5zyT+dXZoIrhQs0aSKCGAYZwR3oAyf+Efs7VpLwmWaeONhG0rltmRzgVgwaRbw/D+C 7ghZrsWwfzxzIARzg9emeK7cqGBBAIPBBpscSQxLHEipGo2qqjAA9MUAcdqsGiweHraXTDCt4rRm 2eE/vGckZz3PfOaq6zAyWmtG3WKEm6iWeRU4SMqN3TnFdhBomm2t0bmCxt45z1kWMA1Z+zQ/vP3S fvfv/KPm+vrQBx8Gkf6dBINV02FXhdNllDsMilep+Y9Ouajt7eCNZdIm+xxyyWzeXf2xHKgj747Z 478811Vroem2Tu9rYW0TOCGKRgEg0W+iabaLKtvYW0azDEgWMDcPegDk5ZoodO1Cya2tIriKKItN aEbJF3YGQOhq/YRWFxrmq/2yIXulcKi3GMLFjjaDx+Vb9to+n2cDw29lbxxOcuioMN9aW90iw1Fk N7ZwTlPumRASKAOIjgt7qXTLX5pdO/tWRYA5OCgUkAeq5rT1EWWjanqTLbD7M9kjSW8fyq7biM8d PrXVfZLfEQ8mPEPMfyj5O3HpRLaW8+/zYY33rsbcoO5fQ+1AHEJJ9l8QXCSfYoBLpjHyrbAXO7vj qfeut0L/AJAdn/1yFLFoWmQOrxWFsjKCoIjGQD1q6iLGgRFCqowABgCgD50FW9KuEtNWtJ5BlI5V J+maqUGmfPp2dzrviJp00et/2koL2l0ilJByo46VycUb3EgjhRpHPRUGTXQ6P42vtLtRaTRxXloO kUwzt+hq6/xBaGJhpuk2lq7Z+fGTQby9nN817Emwn4VhMHcbzbj3qPQ/Fs9kyaNrtt9ptCRHtkX5 0/xrH/4SOb/hH/7L8pdvn+f5mec5zWzF8QmKpJdaTaT3aDCzYxQWqkbpp2INcsLnwn4lmn0VpEhi CvuHIQNzg+1aslzZ+OPDN9cz2qw6lZJu81Bw3+fSsG08aahb6rc3syRXH2oASxyLlcDoBU2q+NpL 3TZLCxsYbGGb/W+X1b8aAVSCvro+h0V9ro0Pwfobmxgu/NUjEv8ADgdq5DXvFN7r6RxTLHDbRnKQ xjAFR6nr8mp6RYWDxKiWedrA8tkYrJoIq1ubRbBRRRQc56T8Jv8AUaj/AL6/yr0OvPPhN/qNR/31 /lXodI9nC/wkFGKKWg6AooooAKKKKACiiigAooooAKKKKACiiigApMUtFACUtFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAHgWt6Lc6HqMlrcowAPyPjhx61n7h6ivoa6sra9j8u6gjmT0dc1n/APCK 6H/0CrT/AL9imedLA6+6zwjI9RRkeor3f/hFND/6BVp/37FH/CKaH/0CrT/v2KCfqMu54TkeooyP UV7t/wAIpof/AECrT/v2KP8AhFND/wCgVaf9+xQH1GXc8JyPUUZHqK92/wCEU0P/AKBVp/37FH/C KaH/ANAq0/79igPqMu54TkeooyPUV7t/wimh/wDQKtP+/Yo/4RTQ/wDoFWn/AH7FAfUJdzwncPUU oyxAUEn0HWvdf+EU0P8A6BVp/wB+xU1toOl2Um+20+3iYd1jANA1gZdzA+HehT6RpEs10pSW6YNs bqoA4rr6BRSO+EFCKihaKKKCwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKAP/9k= --_004_6B22D19DBF96664DBF49BC7B326402B42739A904xmbalnx09ciscoc_-- From nobody Thu Jun 25 14:28:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C7D1B2ACA for ; Thu, 25 Jun 2015 14:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 flxDGOPH_7nu for ; Thu, 25 Jun 2015 14:28:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1F41B2ACD for ; Thu, 25 Jun 2015 14:28:54 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.201.16; Thu, 25 Jun 2015 21:28:51 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0201.000; Thu, 25 Jun 2015 21:28:51 +0000 From: Mike Jones To: "Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco)" , "OAuth@ietf.org" Thread-Topic: JWT Token on-behalf of Use case Thread-Index: AdCvjKZzog4lHzdSReisaGHaz/hQ6gAARPxg Date: Thu, 25 Jun 2015 21:28:51 +0000 Message-ID: References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> In-Reply-To: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::4] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:ZPYqh3OP8aq2PFbtnLLVCfZXmmmI3AdanBYnZuuQ+UDsScabw7gQ5AOGhKCf5HsXx8NskD/i4AeBICMhvC6MMzyyZJMdPD2kg6drXu/p6EdnI9wcFNXYTU3/1oz495dHgecGYgJgLCSrTHz5EWF7qQ==; 24:dKj7l9rzbL96bqq7k5IqKuITOnegmf62q5R96EasJiZu/oCigxcnyW7h2V1E9VqLgz8AFlW1EuPd75m4PkKRqP4xKP+AGHgOFaYzAVWhzjk=; 20:NElPFkLFTP1E8P5+XlcH5MtpvwS3qPeQDq7vUH9KXIarwdqGPnd61U3/+mWZjWzHoP+v6lxduVpbC6buHyUXCQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0618E4E7E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(53754006)(87936001)(2656002)(86362001)(19625215002)(92566002)(17760045003)(5001770100001)(46102003)(50986999)(99936001)(54356999)(76176999)(86612001)(76576001)(99286002)(19609705001)(74316001)(40100003)(18206015028)(19617315012)(19627595001)(77156002)(62966003)(19580405001)(19580395003)(2900100001)(2950100001)(5001960100002)(5003600100002)(5001920100001)(107886002)(5002640100001)(2501003)(122556002)(33656002)(189998001)(102836002)(77096005)(15975445007)(7099028)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/related; boundary="_004_BY2PR03MB442205D40E8F1ECD88082F2F5AE0BY2PR03MB442namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2015 21:28:51.8719 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 21:28:56 -0000 --_004_BY2PR03MB442205D40E8F1ECD88082F2F5AE0BY2PR03MB442namprd_ Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442205D40E8F1ECD88082F2F5AE0BY2PR03MB442namprd_" --_000_BY2PR03MB442205D40E8F1ECD88082F2F5AE0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 = is about. Cheers, -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vivek Biswas -T (v= ibiswas - XORIANT CORPORATION at Cisco) Sent: Thursday, June 25, 2015 2:20 PM To: OAuth@ietf.org Subject: [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which = denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a c= ustomer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, [CISSP] Cisco Systems, Inc Bldg. J, San Jose, USA, Phone: +1 408 527 9176 --_000_BY2PR03MB442205D40E8F1ECD88082F2F5AE0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That’s what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about= .

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Cheers,=

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

From: OAuth [m= ailto:oauth-bounces@ietf.org] On Behalf Of Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisc= o)
Sent: Thursday, June 25, 2015 2:20 PM
To: OAuth@ietf.org
Subject: [OAUTH-WG] JWT Token on-behalf of Use case

 

Hi All,

 

  I am looking to solve a use-case similar to W= S-Security On-Behalf-Of with OAuth JWT Token.

 

  Is there a standard claim which we can define= within the OAuth JWT which denote the On-behalf-of User.

 

For e.g., a Customer Representative trying to create= token on behalf of a customer and trying to execute services specific for = that specific customer.

 

Regards,

Vivek Biswas,
3D"CISSP"

 

Cisco Systems, Inc=

Bldg. J, San Jose, USA,

Phone: +1 408 527 9176

 

--_000_BY2PR03MB442205D40E8F1ECD88082F2F5AE0BY2PR03MB442namprd_-- --_004_BY2PR03MB442205D40E8F1ECD88082F2F5AE0BY2PR03MB442namprd_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=5264; creation-date="Thu, 25 Jun 2015 21:28:50 GMT"; modification-date="Thu, 25 Jun 2015 21:28:50 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAkACQAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCABuAV0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0rWvF ul6E3l3c+6YjPlpy34+lY3/C0dI/543P5CvLLq5lvLqS5uHLyytuZj3NRUHlSxs2/d2PWP8AhaOk f88bn/vkUf8AC0dI/wCeNz/3yK8nopk/Xah6x/wtHSP+eNz/AN8ij/haOkf88bn/AL5FeT0UB9dq HrH/AAtHSP8Anjc/98ij/haOkf8APG5/75FeT0UB9dqHrH/C0dI/543P/fIo/wCFo6R/zxufyFeT 0UB9dqHrH/C0dI/543P/AHyKmtfiVotxKEkMsIPRnXj9K8hooH9dqH0TFKk8SyROrowyGU5BFPrh PhZfSz6VdWsjFkgkHl5PQEZxXd0j0qc+eKkFLRRQaBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfOVFAopnzwUUUUAFFFFABRRRQAUUUUAFFFFA HpHwm/1Go/76/wAq9Erzv4Tf6jUf99f5V6Jmkezhf4SClpKWg6AooooAKKSigBaKKKACiikoAWik ooAWiiigAooooAKKKKACiikoAWiiigAooooAKKKKACiiigAooooA+chRQKKZ88FFFFABRRRQAUUU UAFFFFABRRRQB6R8Jv8AUaj/AL6/yrroNXeXxNdab5YEcMKyB+5JrkvhN/qNR/31/lW7Zf8AJQdQ /wCvZKR61B2pxNnUdXstKRTeTBGc4RACzMfYDmq1l4lsLy6S2BmimkzsSWJl3fQ4xVPSo0ufF2sT z4ee3KRQhv4EKg8fUk1uXcqW9rLcSoGWFS+Mc8DPFB1k9FcLF4p1No4b1T5vmON1mID8qE44b171 pw32t6rfalFZS21vFaT7I2dCS/yg4I/GgDpd67tu4bgMkZ5rPuNesbbT4rySRvLmO2NQp3OfQDr2 rH02K+/4TW/825RtsMe8BOCPQelVorm91W40C8aSFC5clQmcEEg4/CgDqNP1KDUY3aDf+7bawdCp Bxnv9atVy+peJLqyj1ARxo0kd6lrCdpONyA5I74yar23ie6sZ5vtbNeWqwNL5ohMZRl/h+hoA6q8 vIbC1e4uX2RLgFvqQB+pqSWRYYnkkOEQFifQCuN1tNan8Ntd3d3biKRone3WP7ql1wAc9enNdXqf /ILuv+uLfyNAD7S6ivbSK5t23wyqHRvUGi7u4bG1kubmQRwxjLMe1cppV1qT2Gh6fp8kMSSWKySS OuSuMDgVBr9zqFx4fvLW5miMtrdxIZFXAkUsMcdjQB1unalFqcDSwrIqhsfvEKn9auVzouNW1W/u obO4itoLNvKZzHuaSTAJ+g5qq3iHUzHDbRwwG/F2bWXrs6ZDj274oA6ulrlbq516z1Oz0/7XayG6 LHzjEQUA9s80QXHiC4vLuw+02yG0wwuNmTJkZAx296AOppCyrjcQMnAya5f+3bi50i0uZb62sN2U lJQszODj5R6VUkvdQ1fTtKuDPFGxuxGdqHBIB+b/AOtQB1wuo2vGtgT5qIHIxxgkjr+FTVzuo69c aVc3iSok32e0jkUAYLyM5XH04FMuLjXdIhivrye3uYi6i4gRNuwE4yp9vfrQB0tFcrHfa3qM+qvb XFvBBZTMkSmPJkwAfmrf0q8bUNMt7l02NIgLKOx70AXKKKKACiiigAooooAKKKKAPnIUUUUz54KK KKACiiigAooooAKKKKACilpKAPSfhN/qNR/31/lW7Zf8lB1H/r2j/rWF8Jv9RqP++v8AKt2y/wCS hah/17R0j1aP8OJoajojT3wv7C5a0vQuwuBuWRfRh3+tRxaZqs8g/tLUo2g5DQwxACQH1J5qvJf6 rqmrXttpc9vbR2TBGMqb2kYjPTsOetbdo8jW6LcNGblVHmiM8BqDsMe30XVrNVtbbVlWyQ/JuiBk Vc5256e2av6Zpf8AZ1xfS+Zv+1z+djH3flAx+lWZr21t1zPcwxjdty8gHPpz3qpca7Y22oW1o88R e4DYYSLhdoB55754oAhm0i7XXzqFndpGkyqs6OmSQvoaSy8P/Y4tNTz932Ldzj72ST/WtKW9tbeV Y5rmGORvuq8gBP0FOmu7e2UtcTxRKO7uF/nQBk3HhxbgXpNw8ck9ytzE6DmJ1UAfXpSw6VqVyHj1 e/jnt2RozFHEFDgjGSa03v7RPL33UC+b/q8yAb/p60s15bWzKs9xDEz/AHQ7hSfpmgDn5fDmpzWA 059VVrJSu3dEDIVVgQpP4da6G5h+0WssOceYhXPpkUXM4trSacjcI0Z8DvgZrB0i413UYbbUftFn 9luMP9nCHKof9ruaALmm6F/Z8li3nbvstr9n6fe96iv/AA79tivU8/b9pmjlzj7u0g4/StaW9toJ FjmuYY5H+6juAT9AaWe5gtY/MuJo4U6bpHCj8zQBkXGi3kOpT3ek3q2/2kgzxSJuUsBjcPQ4pbXw 2Lb7M5uWkmjna4lkYcyMRj8K14p4plUwyxuGGQVYHI9aXzohn94nB2n5h19KAKV3pf2nV7K98zb9 mDDbj72afBp3k6hd3O/P2gAbcdMCle8WZ42tbu2aJXIl+cHjHQe9RWWu2N9JcJHPEDDIUOZB83AO Rz05oAy4fC9xYy281ndx+dEsiHzY8jDNuyPQihPC94ml/Z/7S3Tx3HnwyGMAKffHrmujZ1TG9guT gZOMmsvxJqFzpumpJZlBM8yRguMgZOOlAED+HWvDcNqVwJHuLVYHMa7cEMWDD8/0pn9hajd+Vb6l qQns4mDbVj2vLjpuP19KVr/U9K1Syg1CWC4t7tzGGRdjI3UcdxWyLu2aYQrcRGVhuCBxuI9cUAU7 DSPsQ1EebuF5M0vT7uRjFWNNs/sFhDbbt3ljG71p8d9azTGGK6geUdUWQFh+FYy6pd6lrdxBY3lr Db2hAcEB2k7nvwBQB0NFQQXlvdbhbXEMxX73luGx9cUkV9azs6w3MMjJ98JICV+vpQBYoqjLepc2 sjafd2rupA3bwyr9cVPPe21pt+03EMO7p5jhc/TNAE9FRNcRIoZ5UVW6MWABpIbu3uIjLBPFJGOr o4IH4igCaiqUuowPY3E1pPDMYkJ+RwwBx3xT9MuXu9Nt55Mb5EDHHSgD58FFAp8UbTTJHGMu7BQP c0z56wzuB3NKQV+8CPqMV314dK8B2sNutnFfatIgd2lGVSqKeOre7Bi1XRbSSEgjdEuGH50G7pRj pKWpx38qUAkZAJA9BXYi1tpPhysoiRWe9278fMFJ9fpWrr2p/wDCIfZLWx0e2ksmjBM0i53nvzQP 2Gl2zzjj1pSCv3gR9Riu58LRafrOt6nqMdghMMXmQ2hAxu+lZ2q+Lv7Q0+8sdQ0i3gnKkRMi4aNs 980E+ySjzNnLY+tFeh3uqReHvCejTw6ZZ3ElwpVzMnoM9qr6ylhf+GtP8QmwS1lWcCWNFwJFB54o KeHSW5wpBHUEd+aSuj8W6zp+rvbnT4guwHcQm3HtXOUGEkk7I9J+E3+o1H/fX+Vbtl/yUHUP+vVK wvhN/qNR/wB9f5V2cWkRxa5PqYkcyTRrGUPQAd6R61BXpxMzV7TSbq6uLhL8WWo2y/PNHJtYcZG4 Hg1lR6nfWVhY66sJllvY/s8yKMb36Rvj8h9DXV3ei6dfTrNd2NvNKvR3jBNVp9PnutdtnkRVsLRC 0YBHzSHjp6AUHUYV5o39nRW9wz2lzNFCzT292R+8J5LKT0PbNTMdOuNS8O3K20MMM0cxxIoH8IwC T1ror3SbHUWRr20gnKfdMiA4pbvS7K+hjiu7WGaOPlFdAQv0oA4iGxk1G61j7ReaYkjTurC6hLOi fwlW3DjHIxWlpumQXGsWUd7ImoGGxAEjD5ZOeu010N1omm3ro11Y28rRjCl4wcD0q0ltDGwZIkVg u0ELggen0oA4zS9FsJ9L1tJIFfyp5EiLcmIAZAU/w8+lRXASK0i1WcWl8Pscfn29wwEigDqh9T+t dwltDGrqkSKJDlwFA3H39aqy6Jps80csthbPJEAEYxjKgdMUATxyxNYrMw2wmIMQw6LjPP4VyV4t npH2W+8O32PtE6j7Gj7o5Qx5wvUV2ZUEYI4xjFU4NE021ujcwWNvHOf+WixgGgDjIrCbULrWBc3m mxzNO6ut3CWkjT+HadwwMdMVdsIrd9bt4NYuIryOKxT7NJKMJKcne2DxnpXTXmjadqEyy3llbzyL 0Z0BNPu9Ksb63WC6tIZYk+6rICF+npQBjQS2Vj4ojSF4YrdrPEW1gEJDEkDt3rnrlodRku1SXfDJ rEalkbqMc4NdtLoemzWcdrJY27W8ZykZjGF+lSx6ZZQoEitIEVWDALGAAR0P1oAxdQ0yysdW0v7L bRxedcYkCjAbCnqKi0zT7C7Os2bpAjSXDIAoAYDaOneuleGORkaRFZkOVJHKn1FU7nToIpZr+0so G1EoQsmAGY/WgDA0b7Vq+qR298GMejEo7HpNL0Vvy5+tXPGyCXRoUZioa5jGQcEc1paHpx0zTUhk bdOxMkz/AN5zyT+dXZoIrhQs0aSKCGAYZwR3oAyf+Efs7VpLwmWaeONhG0rltmRzgVgwaRbw/D+C 7ghZrsWwfzxzIARzg9emeK7cqGBBAIPBBpscSQxLHEipGo2qqjAA9MUAcdqsGiweHraXTDCt4rRm 2eE/vGckZz3PfOaq6zAyWmtG3WKEm6iWeRU4SMqN3TnFdhBomm2t0bmCxt45z1kWMA1Z+zQ/vP3S fvfv/KPm+vrQBx8Gkf6dBINV02FXhdNllDsMilep+Y9Ouajt7eCNZdIm+xxyyWzeXf2xHKgj747Z 478811Vroem2Tu9rYW0TOCGKRgEg0W+iabaLKtvYW0azDEgWMDcPegDk5ZoodO1Cya2tIriKKItN aEbJF3YGQOhq/YRWFxrmq/2yIXulcKi3GMLFjjaDx+Vb9to+n2cDw29lbxxOcuioMN9aW90iw1Fk N7ZwTlPumRASKAOIjgt7qXTLX5pdO/tWRYA5OCgUkAeq5rT1EWWjanqTLbD7M9kjSW8fyq7biM8d PrXVfZLfEQ8mPEPMfyj5O3HpRLaW8+/zYY33rsbcoO5fQ+1AHEJJ9l8QXCSfYoBLpjHyrbAXO7vj qfeut0L/AJAdn/1yFLFoWmQOrxWFsjKCoIjGQD1q6iLGgRFCqowABgCgD50FW9KuEtNWtJ5BlI5V J+maqUGmfPp2dzrviJp00et/2koL2l0ilJByo46VycUb3EgjhRpHPRUGTXQ6P42vtLtRaTRxXloO kUwzt+hq6/xBaGJhpuk2lq7Z+fGTQby9nN817Emwn4VhMHcbzbj3qPQ/Fs9kyaNrtt9ptCRHtkX5 0/xrH/4SOb/hH/7L8pdvn+f5mec5zWzF8QmKpJdaTaT3aDCzYxQWqkbpp2INcsLnwn4lmn0VpEhi CvuHIQNzg+1aslzZ+OPDN9cz2qw6lZJu81Bw3+fSsG08aahb6rc3syRXH2oASxyLlcDoBU2q+NpL 3TZLCxsYbGGb/W+X1b8aAVSCvro+h0V9ro0Pwfobmxgu/NUjEv8ADgdq5DXvFN7r6RxTLHDbRnKQ xjAFR6nr8mp6RYWDxKiWedrA8tkYrJoIq1ubRbBRRRQc56T8Jv8AUaj/AL6/yr0OvPPhN/qNR/31 /lXodI9nC/wkFGKKWg6AooooAKKKKACiiigAooooAKKKKACiiigApMUtFACUtFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAHgWt6Lc6HqMlrcowAPyPjhx61n7h6ivoa6sra9j8u6gjmT0dc1n/APCK 6H/0CrT/AL9imedLA6+6zwjI9RRkeor3f/hFND/6BVp/37FH/CKaH/0CrT/v2KCfqMu54TkeooyP UV7t/wAIpof/AECrT/v2KP8AhFND/wCgVaf9+xQH1GXc8JyPUUZHqK92/wCEU0P/AKBVp/37FH/C KaH/ANAq0/79igPqMu54TkeooyPUV7t/wimh/wDQKtP+/Yo/4RTQ/wDoFWn/AH7FAfUJdzwncPUU oyxAUEn0HWvdf+EU0P8A6BVp/wB+xU1toOl2Um+20+3iYd1jANA1gZdzA+HehT6RpEs10pSW6YNs bqoA4rr6BRSO+EFCKihaKKKCwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKAP/9k= --_004_BY2PR03MB442205D40E8F1ECD88082F2F5AE0BY2PR03MB442namprd_-- From nobody Fri Jun 26 08:44:01 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413021A8837 for ; Fri, 26 Jun 2015 08:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 ztfEqbQDTsf6 for ; Fri, 26 Jun 2015 08:43:57 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) (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 ED1B71A8826 for ; Fri, 26 Jun 2015 08:43:56 -0700 (PDT) Received: by igtg8 with SMTP id g8so4163529igt.0 for ; Fri, 26 Jun 2015 08:43:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=dqks4xh0yjtIYTLQdpsb6RyB+r/5TLnfd+3DbgD+kTk=; b=YJCVrc2ikFRdnfjsHmecbsngUCXr0ygB6tP/3QEaBjLXIoprqwjw8CJwxVz3RL6ZBM UM9orYxwiruyFCGcDsRB2CaOyCusR1a130I6R9m38QjC3u2maadClU1eqj6DcC6WOmSf woi3Kky2MaD4cJIACH0bDL/muu+D/fJ6+B67Cc2idX48BaQSOcUPM69hG1wkUdpcVXit oMDYUhA2y9e9e9mrnk1KakFDAXY8v7V1FXll3iqHhB8HLVmnqPW65lgatTZWWCTqgmxe bXynZ7TgCKOpmC4ElHpyLlmohe1zyITv8p0lwQNJczXiv7XPpf99Aq1VogWoVj9VAj1C j0Cg== X-Gm-Message-State: ALoCoQn198Mp4fzqaupnwFPB+PGF/xGMwHDRDiL1BbLIoBcFdPTQ1UcZ7qQSckBdLrJpAQRvWM66 X-Received: by 10.43.19.131 with SMTP id qk3mr4158425icb.15.1435333436253; Fri, 26 Jun 2015 08:43:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Fri, 26 Jun 2015 08:43:26 -0700 (PDT) From: Brian Campbell Date: Fri, 26 Jun 2015 09:43:26 -0600 Message-ID: To: "" , oauth , "jose@ietf.org" Content-Type: multipart/alternative; boundary=bcaec517cddc9a46cc05196d9b60 Archived-At: Subject: [OAUTH-WG] HTTPS JWKS style key rotation for SAML/XML-DSig X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 15:43:58 -0000 --bcaec517cddc9a46cc05196d9b60 Content-Type: text/plain; charset=UTF-8 This document [0] was something done during the course of some work a few months ago - it briefly proposes how a JWK Key ID can be used within an XML Signature to convey to the recipient what key was used to sign the XML and thusly what key to use to verify the signature. It's not rocket surgery but maybe a useful thing to codify, which might help with migration and coexistence of older and newer protocols. Anyway, no action required or even suggested here. I just wanted to put the idea out there and the mailing lists of a few of these (sorta) related WGs seemed as good a place as any. [0] https://goo.gl/6uWxT7 --bcaec517cddc9a46cc05196d9b60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= a href=3D"https://goo.gl/6uWxT7" target=3D"_blank">This document[0] was= something done during the course of some work a few months ago - it= briefly proposes how a= JWK Key ID can be used within an XML Signature to convey to the recipient = what key was used to sign the XML and thusly what key to use to verify the = signature. It's not rocket surgery but maybe a useful thing to c= odify, which might help with migration and coexistence of older and newer p= rotocols.

Anyway, no action required or even suggested here. = I just wanted to put the idea out there and the mailing lists of a few of t= hese (sorta) related WGs seemed as good a place as any.
--bcaec517cddc9a46cc05196d9b60-- From nobody Fri Jun 26 17:16:09 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1C1B2C12 for ; Fri, 26 Jun 2015 17:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 nV8tE_9Z7FPU for ; Fri, 26 Jun 2015 17:16:07 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 634B31B2C07 for ; Fri, 26 Jun 2015 17:16:07 -0700 (PDT) Received: by obctg8 with SMTP id tg8so76158444obc.3 for ; Fri, 26 Jun 2015 17:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=joz200DX9U4u5pu47wOMnV9CRXVf/IW3/rrfuJDieqA=; b=PcbYxXUG44NaPBXI8HViyPZFsSi3h46cQCT8h9gYRBLOI/NmQEUDcZ/LiWcmsZNVz4 2Bu6w16MiAmkKLXnnEqYk2lXRer4rvRzJMlNerstpAExAtC0k5117WRz3qydjj+QgZ52 x0a+4jiiaLDOsIZ8KVLueWza/fvcuiURC312OUDlP4PhSp1GyF2VqyLHr05oupP5CEup mJel14o47qET2yB+Y5xSb1nMVzf0wY48FpJPDPKGquRG627jU3jAJb0/Gs+QGaZMSZoN YN7s5IQIQuw/myN5kdui6LxSMMTEoCoM6GlLJ5r9JKXhA9CIsBDmLZ2DcQKa+mOtmWGP qV2g== MIME-Version: 1.0 X-Received: by 10.202.66.196 with SMTP id p187mr3523009oia.133.1435364166967; Fri, 26 Jun 2015 17:16:06 -0700 (PDT) Received: by 10.202.172.20 with HTTP; Fri, 26 Jun 2015 17:16:06 -0700 (PDT) Date: Fri, 26 Jun 2015 18:16:06 -0600 Message-ID: From: "I.Valdez" To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a113d688c4ba769051974c3d6 Archived-At: Subject: [OAUTH-WG] OAuth mailing list submission X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 00:16:08 -0000 --001a113d688c4ba769051974c3d6 Content-Type: text/plain; charset=UTF-8 --001a113d688c4ba769051974c3d6 Content-Type: text/html; charset=UTF-8 --001a113d688c4ba769051974c3d6-- From nobody Sun Jun 28 20:53:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83C91B319D for ; Sun, 28 Jun 2015 20:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 5aNYUhLk1-M4 for ; Sun, 28 Jun 2015 20:53:19 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 28DF41B3199 for ; Sun, 28 Jun 2015 20:53:19 -0700 (PDT) Received: by oigb199 with SMTP id b199so109668389oig.3 for ; Sun, 28 Jun 2015 20:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7g7/5ei4et9tFZgnV7Fv6/CgP5F55VkA6p1es9vZbHY=; b=PHsMDubRw1kqjUAc3I5e/UBVhavoCcTriBHeHFdiiNMME5Yfm/u2Ugtj2PL3eLwSZY j1U+9z0dVNuaasTxjHbqqqMrvHwJJmq/V3zLeijXg7A/0lEybu036QBlykwUDNn0MmbT X6UOpihEfBSsR2ND/gWcLplSUCG6O8l5g5gBN8AgOcyiP+ct06V0CAfWZZb1vr05Yw3Y HlsEPuv3eYElBi6/tQ22114DHeMfk108QvvYIPqM9aNdJY/NkmrOZgeN7XwsWNz94EgN /qU5CsHkRJ8eEsC3RQgSXkkatJ22TWQqBcSMe+PBt78jpM0cS3YCH+ajo9KGc1Mux/99 W3bw== MIME-Version: 1.0 X-Received: by 10.202.102.2 with SMTP id a2mr11479620oic.112.1435549998580; Sun, 28 Jun 2015 20:53:18 -0700 (PDT) Received: by 10.60.164.97 with HTTP; Sun, 28 Jun 2015 20:53:18 -0700 (PDT) In-Reply-To: <20150629034750.14270.34911.idtracker@ietfa.amsl.com> References: <20150629034750.14270.34911.idtracker@ietfa.amsl.com> Date: Mon, 29 Jun 2015 12:53:18 +0900 Message-ID: From: Nat Sakimura To: oauth , "oauth-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a1140c0feb90b770519a00775 Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-rjwtprof-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 03:53:21 -0000 --001a1140c0feb90b770519a00775 Content-Type: text/plain; charset=UTF-8 Hi Kepeng and I rev'ed this discussion draft which describes sender confirmation method using JWT against a resource. It is pretty short. Derek and Hannes, We would like to have sometime in the OAuth WG session to discuss about it. I hope you can allocate a bit of time for it. Best, Nat ---------- Forwarded message ---------- From: Date: 2015-06-29 12:47 GMT+09:00 Subject: New Version Notification for draft-sakimura-oauth-rjwtprof-04.txt To: Kepeng Li , Nat Sakimura A new version of I-D, draft-sakimura-oauth-rjwtprof-04.txt has been successfully submitted by Nat Sakimura and posted to the IETF repository. Name: draft-sakimura-oauth-rjwtprof Revision: 04 Title: Sender Constrained JWT for OAuth 2.0 Document date: 2015-06-29 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-sakimura-oauth-rjwtprof-04.txt Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-rjwtprof/ Htmlized: https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-rjwtprof-04 Abstract: This discussion document describes a method to indicate a sender constraint within JWT. It could potentially be incorporated into POPS spec [POPS]. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1140c0feb90b770519a00775 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Kepeng and I rev'ed this discuss= ion draft which describes sender confirmation method=C2=A0
using = JWT against a resource.=C2=A0

It is pretty short.= =C2=A0

Derek and Hannes,=C2=A0

We would like to have sometime in the OAuth WG session to discuss abo= ut it.=C2=A0
I hope you can allocate a bit of time for it.=C2=A0<= /div>

Best,=C2=A0

Nat

---------- Forwarded message ----------
= From: <internet-drafts@ietf.org>
= Date: 2015-06-29 12:47 GMT+09:00
Subject: New Version Notification for d= raft-sakimura-oauth-rjwtprof-04.txt
To: Kepeng Li <kepeng.lkp@alibaba-inc.com>, Nat Sakimur= a <sakimura@gmail.com>
<= br>

A new version of I-D, draft-sakimura-oauth-rjwtprof-04.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sakimura-oauth-rjwtprof=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sender Constrained JWT for OAuth 2= .0
Document date:=C2=A0 2015-06-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-sakimura-oaut= h-rjwtprof-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-sakimura-oauth-rjwtprof/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-04
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-sakimura-oauth-rjwt= prof-04

Abstract:
=C2=A0 =C2=A0This discussion document describes a method to indicate a send= er
=C2=A0 =C2=A0constraint within JWT.=C2=A0 It could potentially be incorpora= ted into
=C2=A0 =C2=A0POPS spec [POPS].





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
= @_nat_en
--001a1140c0feb90b770519a00775-- From nobody Mon Jun 29 08:22:32 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1261A1B1D for ; Mon, 29 Jun 2015 08:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Ul-afVMdfaAZ for ; Mon, 29 Jun 2015 08:22:29 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 C34E21A1ADA for ; Mon, 29 Jun 2015 08:22:28 -0700 (PDT) Received: by oiax193 with SMTP id x193so120359957oia.2 for ; Mon, 29 Jun 2015 08:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a7dR2i2hbXz73cZczitw6JOJCJjH4HnjjohFUi3WIv8=; b=Wh3/Ae3qvYtieZVCmmM+u64tHhFVkcmN08U6g/03kp5ArL1v5QNDxi+IELtKu49Bbz gLgdhtne1X0YRASvxAh9KxmsLXSu1Jk6bw+aNsgluEDyzyLxL3XLgCtLSjAGBXVINeMP A0MO+ipLFFbhtnmofn7wDLIg4XQYm/HXH3S+Ks0MIcqNPGZwc7oQXqzbuH5mnBXgU6ES s0iZXzk9AT9qm6mtY92EBU4bYqD5CP+ml0bvzeIgmkJzr45fkmHoU4hVq0/d2AGDVD1Z bYBVwkXKhkuGl9q6Dh3hwt588+CZCrV7MAZA9Ed0ThmshflkwarOZm9d13t0esR5tuh4 DVAw== MIME-Version: 1.0 X-Received: by 10.182.186.2 with SMTP id fg2mr12606522obc.35.1435591348262; Mon, 29 Jun 2015 08:22:28 -0700 (PDT) Received: by 10.60.164.97 with HTTP; Mon, 29 Jun 2015 08:22:28 -0700 (PDT) In-Reply-To: <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com> References: <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com> Date: Tue, 30 Jun 2015 00:22:28 +0900 Message-ID: From: Nat Sakimura To: Antonio Sanso Content-Type: multipart/alternative; boundary=089e0141a71a5b1c8c0519a9a848 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 15:22:31 -0000 --089e0141a71a5b1c8c0519a9a848 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Year, from my skimming of the paper, it requires a page that executes arbitrary callback function given as a parameter. It is absolutely stupid to do it, but apparently there are such pages. Prime candidate happens to be OAuth Redirection Endpoint. By itself, it probably will not do much harm because you cannot do much things in that window itself, but if the window is a pop-up and keeps a parent context, it will essentially be able to remote control the parent window to do much more harm. So, it is not OAuth problem per se. However, it may be worthwhile to tell the developers to make sure that redirection endpoint accepts only valid oauth payload, and do not execute anything in the parameter. Nat 2015-06-25 19:48 GMT+09:00 Antonio Sanso : > hi John > > On Jun 25, 2015, at 1:42 AM, John Bradley wrote: > > Thanks for the info, > > As I read it, this is an attack on Java Script callbacks. > > The information tying it to OAuth is not clear. > > Is the issue relating to JS people using the implicit flow and the JS > loaded from the client somehow being vulnerable? > > Or is this happening in the JS after authorization in calls to other > resources from the same origin, and it is just coincidence that people ar= e > using OAuth. > > > is more the second one :) Extrapolating from the white paper [0] > > "The most common technique tasked with ful=1Clling > the above described need is OAuth. In order to gain access to third-party > resources > using OAuth, the service shall utilize a third-party endpoint (OAuth > dialog) that will > ask for the resource owner's approval. The problem with this process is > that redirecting > the service to an OAuth dialog means losing the content of the currently > open service > document. For overcoming this problem, developers open a pop-up window to > display > the dialog in a singular browsing context. Once the user permits or denie= s > access to > the service, the OAuth dialog pop-up will be redirected to render a > callback endpoint > hosted on the service domain. This document should eventually notify the > service that > the process has been completed. > For the new pop-up window to notify the service window upon approval, > denial or for > it to transfer access tokens or similar data, developers may implement > callback endpoints > that use a script referencing the "opener" window for executing a callbac= k > method of the > service. When developers also opted for providing the service with the > decision on how > to "call it back" through a callback parameter, the entire domain becomes > vulnerable to > SOME." > > regards > > antonio > > [0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf > > > Understanding if there is any Oauth specific advice to give would be > helpful. I see there are ways to prevent the SOME exploit. > > Regards > John B. > > > On Jun 24, 2015, at 4:18 PM, Antonio Sanso wrote: > > hi *, just sharing. > > Not directly related to OAuth per se but it exploits several OAuth client > endpoints due to some common developers pattern > http://www.benhayak.com/2015/06/same-origin-method-execution-some.html > (concrete example in > http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google= .html > ) > > regards > > antonio > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e0141a71a5b1c8c0519a9a848 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Year, from my skimming of the paper, it requires a pa= ge that executes arbitrary callback function given as a parameter.=C2=A0
It is absolutely stupid to do it, but apparently there are such pag= es.=C2=A0
Prime candidate happens to be OAuth Redirection Endpoin= t.=C2=A0
By itself, it probably will not do much harm because you= cannot do much things in that window itself,=C2=A0
but if the wi= ndow is a pop-up and keeps a parent context, it will essentially be able to= =C2=A0
remote control the parent window to do much more harm.=C2= =A0

So, it is not OAuth problem per se.=C2=A0

However, it may be worthwhile to tell the developers t= o make sure that redirection endpoint=C2=A0
accepts only valid oa= uth payload, and do not execute anything in the parameter.=C2=A0
=
Nat

2015-06-25 19:48 GMT+09:00 Antonio Sanso <= ;asanso@adobe.com= >:
hi John

On Jun 25, 2015, at 1:42 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks for the info,

As I read it, this is an attack on Java Script callbacks.

The information tying it to OAuth is not clear.

Is the issue relating to JS people using the implicit flow and the JS loade= d from the client somehow being vulnerable?

Or is this happening in the JS after authorization in calls to other resour= ces from the same origin, and it is just coincidence that people are using = OAuth.

 is more the second one :) Extrapolating from the white paper [0]

"The most common technique tasked with ful=1Clling
the above described need is OAuth. In order to gain access to third-pa= rty resources
using OAuth, the service shall utilize a third-party endpoint (OAuth d= ialog) that will
ask for the resource owner's approval. The problem with this proce= ss is that redirecting
the service to an OAuth dialog means losing the content of the current= ly open service
document. For overcoming this problem, developers open a pop-up window= to display
the dialog in a singular browsing context. Once the user permits or de= nies access to
the service, the OAuth dialog pop-up will be redirected to render a ca= llback endpoint
hosted on the service domain. This document should eventually notify t= he service that
the process has been completed.
For the new pop-up window to notify the service window upon approval, = denial or for
it to transfer access tokens or similar data, developers may implement= callback endpoints
that use a script referencing the "opener" window for execut= ing a callback method of the
service. When developers also opted for providing the service with the= decision on how
to "call it back" through a callback parameter, the entire d= omain becomes vulnerable to
SOME."

regards

antonio



Understanding if there is any Oauth specific advice to give would be helpfu= l. =C2=A0=C2=A0I see there are ways to prevent the SOME exploit.

Regards
John B.


On Jun 24, 2015, at 4:18 PM, Antonio Sanso <asanso@adobe.com>= ; wrote:

hi *, just sharing.

Not directly related to OAuth per se but it exploits several OAuth client e= ndpoints due to some common developers pattern http://www.benhayak.com/2015/06/same-origin-method-execution-some.html = (concrete example in http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.h= tml)

regards

antonio
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--089e0141a71a5b1c8c0519a9a848-- From nobody Mon Jun 29 08:22:59 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FE21A1B20 for ; Mon, 29 Jun 2015 08:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 HKvjIiIXu0Nj for ; Mon, 29 Jun 2015 08:22:55 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 3B4651A1B4A for ; Mon, 29 Jun 2015 08:22:55 -0700 (PDT) Received: by obpn3 with SMTP id n3so106928170obp.0 for ; Mon, 29 Jun 2015 08:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lRqb8XAaLCu4amPGCLpA80MkVVdrSJYPbpQKs2l244Q=; b=qUT5kk7rFCIxCJWTJ9CouDXi6/I3hyr9fUAH5IYQOFCGDhtidjS0qRJ/Lq3Jlli4f8 CmKGAzsg7LOL0CWTm2+Q4uCXYkHrF8MzmYdrOB28FwUGjKpZc+PY559X+Chxxg6qfOxo 1OX3PZFoVBvc+tHn1fc0P2tVC6poyl9r6hLNP9NH6bJPPSYiKBZATky0nCTHgqp3Ji74 q3xGF2oC0gKXccFdyqTL4di82hiqQBbFo9Nw00N0rgwZVSKmFBO7fsK9F97yCyTTo124 8cA4dVr0xA0LeYY0A7y3D4rfQR5Sqs6YmGrGbGihFzzGfszP6D3RBI3DB8dGp8XXZKZe +akA== MIME-Version: 1.0 X-Received: by 10.60.79.97 with SMTP id i1mr15087308oex.44.1435591374718; Mon, 29 Jun 2015 08:22:54 -0700 (PDT) Received: by 10.60.164.97 with HTTP; Mon, 29 Jun 2015 08:22:54 -0700 (PDT) In-Reply-To: References: <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com> Date: Tue, 30 Jun 2015 00:22:54 +0900 Message-ID: From: Nat Sakimura To: Antonio Sanso Content-Type: multipart/alternative; boundary=089e011848e8eecd4a0519a9a9a7 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 15:22:57 -0000 --089e011848e8eecd4a0519a9a9a7 Content-Type: text/plain; charset=UTF-8 s/Year/Yeah/ 2015-06-30 0:22 GMT+09:00 Nat Sakimura : > Year, from my skimming of the paper, it requires a page that executes > arbitrary callback function given as a parameter. > It is absolutely stupid to do it, but apparently there are such pages. > Prime candidate happens to be OAuth Redirection Endpoint. > By itself, it probably will not do much harm because you cannot do much > things in that window itself, > but if the window is a pop-up and keeps a parent context, it will > essentially be able to > remote control the parent window to do much more harm. > > So, it is not OAuth problem per se. > > However, it may be worthwhile to tell the developers to make sure that > redirection endpoint > accepts only valid oauth payload, and do not execute anything in the > parameter. > > Nat > > 2015-06-25 19:48 GMT+09:00 Antonio Sanso : > >> hi John >> >> On Jun 25, 2015, at 1:42 AM, John Bradley wrote: >> >> Thanks for the info, >> >> As I read it, this is an attack on Java Script callbacks. >> >> The information tying it to OAuth is not clear. >> >> Is the issue relating to JS people using the implicit flow and the JS >> loaded from the client somehow being vulnerable? >> >> Or is this happening in the JS after authorization in calls to other >> resources from the same origin, and it is just coincidence that people are >> using OAuth. >> >> >> is more the second one :) Extrapolating from the white paper [0] >> >> "The most common technique tasked with ful lling >> the above described need is OAuth. In order to gain access to third-party >> resources >> using OAuth, the service shall utilize a third-party endpoint (OAuth >> dialog) that will >> ask for the resource owner's approval. The problem with this process is >> that redirecting >> the service to an OAuth dialog means losing the content of the currently >> open service >> document. For overcoming this problem, developers open a pop-up window to >> display >> the dialog in a singular browsing context. Once the user permits or >> denies access to >> the service, the OAuth dialog pop-up will be redirected to render a >> callback endpoint >> hosted on the service domain. This document should eventually notify the >> service that >> the process has been completed. >> For the new pop-up window to notify the service window upon approval, >> denial or for >> it to transfer access tokens or similar data, developers may implement >> callback endpoints >> that use a script referencing the "opener" window for executing a >> callback method of the >> service. When developers also opted for providing the service with the >> decision on how >> to "call it back" through a callback parameter, the entire domain becomes >> vulnerable to >> SOME." >> >> regards >> >> antonio >> >> [0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf >> >> >> Understanding if there is any Oauth specific advice to give would be >> helpful. I see there are ways to prevent the SOME exploit. >> >> Regards >> John B. >> >> >> On Jun 24, 2015, at 4:18 PM, Antonio Sanso wrote: >> >> hi *, just sharing. >> >> Not directly related to OAuth per se but it exploits several OAuth client >> endpoints due to some common developers pattern >> http://www.benhayak.com/2015/06/same-origin-method-execution-some.html >> (concrete example in >> http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.html >> ) >> >> regards >> >> antonio >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e011848e8eecd4a0519a9a9a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
s/Year/Yeah/

2015-06-30 0:22 GMT+09:00 Nat Sakimura = <sakimura@gmail.= com>:
Year, from my skimming of the paper, it requires a page that executes arbi= trary callback function given as a parameter.=C2=A0
It is absolut= ely stupid to do it, but apparently there are such pages.=C2=A0
P= rime candidate happens to be OAuth Redirection Endpoint.=C2=A0
By= itself, it probably will not do much harm because you cannot do much thing= s in that window itself,=C2=A0
but if the window is a pop-up and = keeps a parent context, it will essentially be able to=C2=A0
remo= te control the parent window to do much more harm.=C2=A0

So, it is not OAuth problem per se.=C2=A0

H= owever, it may be worthwhile to tell the developers to make sure that redir= ection endpoint=C2=A0
accepts only valid oauth payload, and do no= t execute anything in the parameter.=C2=A0

Nat

2015-06-25 19:48 GMT+09:00 Antonio Sanso &l= t;asanso@adobe.com>:
hi John


Thanks for the info,

As I read it, this is an attack on Java Script callbacks.

The information tying it to OAuth is not clear.

Is the issue relating to JS people using the implicit flow and the JS loade= d from the client somehow being vulnerable?

Or is this happening in the JS after authorization in calls to other resour= ces from the same origin, and it is just coincidence that people are using = OAuth.

is more the second one :) Extrapolating from the white paper [0]

"The most common technique tasked with ful lling
the above described need is OAuth. In order to gain access to third-pa= rty resources
using OAuth, the service shall utilize a third-party endpoint (OAuth d= ialog) that will
ask for the resource owner's approval. The problem with this proce= ss is that redirecting
the service to an OAuth dialog means losing the content of the current= ly open service
document. For overcoming this problem, developers open a pop-up window= to display
the dialog in a singular browsing context. Once the user permits or de= nies access to
the service, the OAuth dialog pop-up will be redirected to render a ca= llback endpoint
hosted on the service domain. This document should eventually notify t= he service that
the process has been completed.
For the new pop-up window to notify the service window upon approval, = denial or for
it to transfer access tokens or similar data, developers may implement= callback endpoints
that use a script referencing the "opener" window for execut= ing a callback method of the
service. When developers also opted for providing the service with the= decision on how
to "call it back" through a callback parameter, the entire d= omain becomes vulnerable to
SOME."

regards

antonio



Understanding if there is any Oauth specific advice to give would be helpfu= l. =C2=A0=C2=A0I see there are ways to prevent the SOME exploit.

Regards
John B.


On Jun 24, 2015, at 4:18 PM, Antonio Sanso <asanso@adobe.com>= ; wrote:

hi *, just sharing.

Not directly related to OAuth per se but it exploits several OAuth client e= ndpoints due to some common developers pattern http://www.benhayak.com/2015/06/same-origin-method-execution-some.html = (concrete example in http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.h= tml)

regards

antonio
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dna= t)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation<= br>http://nat.sakimu= ra.org/
@_nat_en
--089e011848e8eecd4a0519a9a9a7-- From nobody Mon Jun 29 08:36:37 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279F91ACE1F for ; Mon, 29 Jun 2015 08:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 ln1DHZQHxT_3 for ; Mon, 29 Jun 2015 08:36:28 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5041ACE1B for ; Mon, 29 Jun 2015 08:36:27 -0700 (PDT) X-AuditID: 1209190c-f79296d000000622-27-559165f96cd3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id C7.6B.01570.9F561955; Mon, 29 Jun 2015 11:36:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t5TFaPIV014596; Mon, 29 Jun 2015 11:36:25 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5TFaNqU008358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Jun 2015 11:36:24 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_6C82EF66-62B3-4525-9C97-D1FAC0AF1E0B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: Date: Mon, 29 Jun 2015 11:36:22 -0400 Message-Id: <14F3933F-C943-4B7E-8C92-11CB227FB1A7@mit.edu> References: <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com> To: Nat Sakimura X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixCmqrfszdWKowdLf1hYnL/SzWJx8+4rN 4sytFYwOzB7TfvYwe+ycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGSs//mMp2FNecXNiB1MD 4/O0LkZODgkBE4n/VyezQ9hiEhfurWfrYuTiEBJYzCQx7+IjVghnI6PEg1troZyHTBJts/8w dzFycDALJEg8WWQF0s0roCfx6OljsEnCAtYSFxddZAGx2QRUJaavaWECsTkFAiU2H9zEAtLK AhSfdU8YJMws4Cnx7Wg3M8QYK4nZM59BHbGSSeLwvndgCRGg+qa9h1lBeiUEZCW+bpWbwCgw C+GIWUiOmAU2VVti2cLXzBC2psT+7uUsmOIaEp3fJrIuYGRbxSibklulm5uYmVOcmqxbnJyY l5dapGuol5tZopeaUrqJERwBkjw7GN8cVDrEKMDBqMTD22A/IVSINbGsuDL3EKMkB5OSKC+r x8RQIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8TLFAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLp iSWp2ampBalFMFkZDg4lCV4uYKQLCRalpqdWpGXmlCCkmTg4QYbzAA3fkQIyvLggMbc4Mx0i f4pRUUqcdyNIQgAkkVGaB9cLS1CvGMWBXhHmtQBZwQNMbnDdr4AGMwENXuXdBzK4JBEhJdXA mOL/JfPAltk7b27oVln0skF5k77xBOa91etlL6077lVY4nRudv2mdSbdl7asXZOyJOPJ+R3H 3olJ+v5dE33ftDaGu3fLgUfT+12yjZakLHzYleVQ2sl7Q+/UTlMpOdmFkwJ+npjSnBkgO2PR kiuyi/kv3JGUOLf9u7u198mjG3bWL3gvWC3/b68SS3FGoqEWc1FxIgDhr7v3KwMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 15:36:32 -0000 --Apple-Mail=_6C82EF66-62B3-4525-9C97-D1FAC0AF1E0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Right, even though it=E2=80=99s not an OAuth problem, it=E2=80=99s a = problem that is more likely to come up and cause damage in situations = that OAuth brings about (the pop-up redirect page that Nat mentions). = So, just like the advice to use the system browser on mobile platforms, = I think it=E2=80=99d be good to have actual advice for developers so = that they can avoid doing this. =E2=80=94 Justin > On Jun 29, 2015, at 11:22 AM, Nat Sakimura wrote: >=20 > s/Year/Yeah/ >=20 > 2015-06-30 0:22 GMT+09:00 Nat Sakimura >: > Year, from my skimming of the paper, it requires a page that executes = arbitrary callback function given as a parameter.=20 > It is absolutely stupid to do it, but apparently there are such pages.=20= > Prime candidate happens to be OAuth Redirection Endpoint.=20 > By itself, it probably will not do much harm because you cannot do = much things in that window itself,=20 > but if the window is a pop-up and keeps a parent context, it will = essentially be able to=20 > remote control the parent window to do much more harm.=20 >=20 > So, it is not OAuth problem per se.=20 >=20 > However, it may be worthwhile to tell the developers to make sure that = redirection endpoint=20 > accepts only valid oauth payload, and do not execute anything in the = parameter.=20 >=20 > Nat >=20 > 2015-06-25 19:48 GMT+09:00 Antonio Sanso >: > hi John >=20 > On Jun 25, 2015, at 1:42 AM, John Bradley > wrote: >=20 >> Thanks for the info, >>=20 >> As I read it, this is an attack on Java Script callbacks.=20 >>=20 >> The information tying it to OAuth is not clear. >>=20 >> Is the issue relating to JS people using the implicit flow and the JS = loaded from the client somehow being vulnerable? >>=20 >> Or is this happening in the JS after authorization in calls to other = resources from the same origin, and it is just coincidence that people = are using OAuth. >=20 > is more the second one :) Extrapolating from the white paper [0] >=20 > "The most common technique tasked with ful lling > the above described need is OAuth. In order to gain access to = third-party resources > using OAuth, the service shall utilize a third-party endpoint (OAuth = dialog) that will > ask for the resource owner's approval. The problem with this process = is that redirecting > the service to an OAuth dialog means losing the content of the = currently open service > document. For overcoming this problem, developers open a pop-up window = to display > the dialog in a singular browsing context. Once the user permits or = denies access to > the service, the OAuth dialog pop-up will be redirected to render a = callback endpoint > hosted on the service domain. This document should eventually notify = the service that > the process has been completed. > For the new pop-up window to notify the service window upon approval, = denial or for > it to transfer access tokens or similar data, developers may implement = callback endpoints > that use a script referencing the "opener" window for executing a = callback method of the > service. When developers also opted for providing the service with the = decision on how > to "call it back" through a callback parameter, the entire domain = becomes vulnerable to > SOME." >=20 > regards >=20 > antonio >=20 > [0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf = >=20 >>=20 >> Understanding if there is any Oauth specific advice to give would be = helpful. I see there are ways to prevent the SOME exploit. >>=20 >> Regards >> John B. >>=20 >>=20 >>> On Jun 24, 2015, at 4:18 PM, Antonio Sanso > wrote: >>>=20 >>> hi *, just sharing. >>>=20 >>> Not directly related to OAuth per se but it exploits several OAuth = client endpoints due to some common developers pattern = http://www.benhayak.com/2015/06/same-origin-method-execution-some.html = = (concrete example in = http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.= html = ) >>>=20 >>> regards >>>=20 >>> antonio >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6C82EF66-62B3-4525-9C97-D1FAC0AF1E0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Right, even though it=E2=80=99s not an OAuth problem, it=E2=80=99= s a problem that is more likely to come up and cause damage in = situations that OAuth brings about (the pop-up redirect page that Nat = mentions). So, just like the advice to use the system browser on mobile = platforms, I think it=E2=80=99d be good to have actual advice for = developers so that they can avoid doing this.

 =E2=80=94 Justin

On Jun 29, 2015, at 11:22 AM, Nat Sakimura <sakimura@gmail.com> = wrote:

s/Year/Yeah/

2015-06-30= 0:22 GMT+09:00 Nat Sakimura <sakimura@gmail.com>:
Year, = from my skimming of the paper, it requires a page that executes = arbitrary callback function given as a parameter. 
It is absolutely stupid to do it, but apparently there are = such pages. 
Prime candidate happens to be = OAuth Redirection Endpoint. 
By itself, it = probably will not do much harm because you cannot do much things in that = window itself, 
but if the window is a pop-up = and keeps a parent context, it will essentially be able = to 
remote control the parent window to do = much more harm. 

So, it is not OAuth problem per se. 

However, it may be = worthwhile to tell the developers to make sure that redirection = endpoint 
accepts only valid oauth payload, = and do not execute anything in the parameter. 

Nat

2015-06-25 19:48 GMT+09:00 Antonio = Sanso <asanso@adobe.com>:
hi John

On Jun 25, 2015, at 1:42 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Thanks for the info,

As I read it, this is an attack on Java Script callbacks.

The information tying it to OAuth is not clear.

Is the issue relating to JS people using the implicit flow and the JS = loaded from the client somehow being vulnerable?

Or is this happening in the JS after authorization in calls to other = resources from the same origin, and it is just coincidence that people = are using OAuth.

 is more the second one :) Extrapolating from the white paper [0]

"The most common technique tasked with ful lling
the above described need is OAuth. In order to gain = access to third-party resources
using OAuth, the service shall utilize a third-party = endpoint (OAuth dialog) that will
ask for the resource owner's approval. The problem with = this process is that redirecting
the service to an OAuth dialog means losing the content = of the currently open service
document. For overcoming this problem, developers open a = pop-up window to display
the dialog in a singular browsing context. Once the user = permits or denies access to
the service, the OAuth dialog pop-up will be redirected = to render a callback endpoint
hosted on the service domain. This document should = eventually notify the service that
the process has been completed.
For the new pop-up window to notify the service window = upon approval, denial or for
it to transfer access tokens or similar data, developers = may implement callback endpoints
that use a script referencing the "opener" window for = executing a callback method of the
service. When developers also opted for providing the = service with the decision on how
to "call it back" through a callback parameter, the = entire domain becomes vulnerable to
SOME."

regards

antonio

[0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.p= df


Understanding if there is any Oauth specific advice to give would be = helpful.   I see there are ways to prevent the SOME = exploit.

Regards
John B.


On Jun 24, 2015, at 4:18 PM, = Antonio Sanso <asanso@adobe.com> wrote:

hi *, just sharing.

Not directly related to OAuth per se but it exploits several OAuth = client endpoints due to some common developers pattern = http://www.benhayak.com/2015/06/same-origin-method-execution-some.html= (concrete example in = http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.= html)

regards

antonio
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura (=3Dnat)
Chairman, OpenID = Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_6C82EF66-62B3-4525-9C97-D1FAC0AF1E0B-- From nobody Mon Jun 29 09:25:58 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6BA1AD0D6 for ; Mon, 29 Jun 2015 09:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 2hNnIAF1gTEI for ; Mon, 29 Jun 2015 09:25:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8FF1ACEBB for ; Mon, 29 Jun 2015 09:25:54 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t5TGPrBP005347 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Jun 2015 16:25:53 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t5TGPqON017944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Jun 2015 16:25:52 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t5TGPqP5025742; Mon, 29 Jun 2015 16:25:52 GMT Received: from [10.0.1.13] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jun 2015 09:25:52 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-EFDD0985-AE75-4927-AC1F-8E3E9D26CA2B Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (12F70) In-Reply-To: <14F3933F-C943-4B7E-8C92-11CB227FB1A7@mit.edu> Date: Mon, 29 Jun 2015 09:25:50 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com> <14F3933F-C943-4B7E-8C92-11CB227FB1A7@mit.edu> To: Justin Richer X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 16:25:57 -0000 --Apple-Mail-EFDD0985-AE75-4927-AC1F-8E3E9D26CA2B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Or maybe another wg should address (http)? Phil > On Jun 29, 2015, at 08:36, Justin Richer wrote: >=20 > Right, even though it=E2=80=99s not an OAuth problem, it=E2=80=99s a probl= em that is more likely to come up and cause damage in situations that OAuth b= rings about (the pop-up redirect page that Nat mentions). So, just like the a= dvice to use the system browser on mobile platforms, I think it=E2=80=99d be= good to have actual advice for developers so that they can avoid doing this= . >=20 > =E2=80=94 Justin >=20 >> On Jun 29, 2015, at 11:22 AM, Nat Sakimura wrote: >>=20 >> s/Year/Yeah/ >>=20 >> 2015-06-30 0:22 GMT+09:00 Nat Sakimura : >>> Year, from my skimming of the paper, it requires a page that executes ar= bitrary callback function given as a parameter.=20 >>> It is absolutely stupid to do it, but apparently there are such pages.=20= >>> Prime candidate happens to be OAuth Redirection Endpoint.=20 >>> By itself, it probably will not do much harm because you cannot do much t= hings in that window itself,=20 >>> but if the window is a pop-up and keeps a parent context, it will essent= ially be able to=20 >>> remote control the parent window to do much more harm.=20 >>>=20 >>> So, it is not OAuth problem per se.=20 >>>=20 >>> However, it may be worthwhile to tell the developers to make sure that r= edirection endpoint=20 >>> accepts only valid oauth payload, and do not execute anything in the par= ameter.=20 >>>=20 >>> Nat >>>=20 >>> 2015-06-25 19:48 GMT+09:00 Antonio Sanso : >>>> hi John >>>>=20 >>>>> On Jun 25, 2015, at 1:42 AM, John Bradley wrote: >>>>>=20 >>>>> Thanks for the info, >>>>>=20 >>>>> As I read it, this is an attack on Java Script callbacks.=20 >>>>>=20 >>>>> The information tying it to OAuth is not clear. >>>>>=20 >>>>> Is the issue relating to JS people using the implicit flow and the JS l= oaded from the client somehow being vulnerable? >>>>>=20 >>>>> Or is this happening in the JS after authorization in calls to other r= esources from the same origin, and it is just coincidence that people are us= ing OAuth. >>>>=20 >>>> is more the second one :) Extrapolating from the white paper [0] >>>>=20 >>>> "The most common technique tasked with ful lling >>>> the above described need is OAuth. In order to gain access to third-par= ty resources >>>> using OAuth, the service shall utilize a third-party endpoint (OAuth di= alog) that will >>>> ask for the resource owner's approval. The problem with this process is= that redirecting >>>> the service to an OAuth dialog means losing the content of the currentl= y open service >>>> document. For overcoming this problem, developers open a pop-up window t= o display >>>> the dialog in a singular browsing context. Once the user permits or den= ies access to >>>> the service, the OAuth dialog pop-up will be redirected to render a cal= lback endpoint >>>> hosted on the service domain. This document should eventually notify th= e service that >>>> the process has been completed. >>>> For the new pop-up window to notify the service window upon approval, d= enial or for >>>> it to transfer access tokens or similar data, developers may implement c= allback endpoints >>>> that use a script referencing the "opener" window for executing a callb= ack method of the >>>> service. When developers also opted for providing the service with the d= ecision on how >>>> to "call it back" through a callback parameter, the entire domain becom= es vulnerable to >>>> SOME." >>>>=20 >>>> regards >>>>=20 >>>> antonio >>>>=20 >>>> [0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf >>>>=20 >>>>>=20 >>>>> Understanding if there is any Oauth specific advice to give would be h= elpful. I see there are ways to prevent the SOME exploit. >>>>>=20 >>>>> Regards >>>>> John B. >>>>>=20 >>>>>=20 >>>>>> On Jun 24, 2015, at 4:18 PM, Antonio Sanso wrote: >>>>>>=20 >>>>>> hi *, just sharing. >>>>>>=20 >>>>>> Not directly related to OAuth per se but it exploits several OAuth cl= ient endpoints due to some common developers pattern http://www.benhayak.com= /2015/06/same-origin-method-execution-some.html (concrete example in http://= www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.html) >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> antonio >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> --=20 >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-EFDD0985-AE75-4927-AC1F-8E3E9D26CA2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Or maybe another wg should address (ht= tp)?

Phil

On Jun 29, 2015, at 08:36, Justin Richer <= jricher@mit.edu> wrote:

Right, even though it=E2=80=99s not an OAuth pro= blem, it=E2=80=99s a problem that is more likely to come up and cause damage= in situations that OAuth brings about (the pop-up redirect page that Nat me= ntions). So, just like the advice to use the system browser on mobile platfo= rms, I think it=E2=80=99d be good to have actual advice for developers so th= at they can avoid doing this.

 =E2=80=94 Justin

On Jun 29, 2015, at 11:22 AM,= Nat Sakimura <sakimura@= gmail.com> wrote:

s/Year/Yeah/

2015-06-30 0:22 GMT+= 09:00 Nat Sakimura <sakimura@gmail.com>= :
Year, from my skimming of the paper, it requires a page that e= xecutes arbitrary callback function given as a parameter. 
It is absolutely stupid to do it, but apparently there are such pag= es. 
Prime candidate happens to be OAuth Redirecti= on Endpoint. 
By itself, it probably will not do m= uch harm because you cannot do much things in that window itself, 
but if the window is a pop-up and keeps a parent context, i= t will essentially be able to 
remote control the p= arent window to do much more harm. 

So, it is not OAuth problem per se. 

However, it may be worthwhile= to tell the developers to make sure that redirection endpoint 
accepts only valid oauth payload, and do not execute anything i= n the parameter. 

Nat

2015-06-25 19:48 GMT+09:00 Anto= nio Sanso <asanso@adobe.com>:
hi John

On Jun 25, 2015, at 1:42 AM, John Bradley <ve7jtb@ve7jtb.com>= ; wrote:

Thanks for the info,

As I read it, this is an attack on Java Script callbacks.

The information tying it to OAuth is not clear.

Is the issue relating to JS people using the implicit flow and the JS loaded= from the client somehow being vulnerable?

Or is this happening in the JS after authorization in calls to other resourc= es from the same origin, and it is just coincidence that people are using OA= uth.

 is more the second one :) Extrapolating from the white paper [0]

"The most common technique tasked with ful lling
the above described need is OAuth. In order to gain access t= o third-party resources
using OAuth, the service shall utilize a third-party endpoin= t (OAuth dialog) that will
ask for the resource owner's approval. The problem with this= process is that redirecting
the service to an OAuth dialog means losing the content of t= he currently open service
document. For overcoming this problem, developers open a pop= -up window to display
the dialog in a singular browsing context. Once the user per= mits or denies access to
the service, the OAuth dialog pop-up will be redirected to r= ender a callback endpoint
hosted on the service domain. This document should eventuall= y notify the service that
the process has been completed.
For the new pop-up window to notify the service window upon a= pproval, denial or for
it to transfer access tokens or similar data, developers may= implement callback endpoints
that use a script referencing the "opener" window for execut= ing a callback method of the
service. When developers also opted for providing the servic= e with the decision on how
to "call it back" through a callback parameter, the entire d= omain becomes vulnerable to
SOME."

regards

antonio

[0] http://files.benhaya= k.com/Same_Origin_Method_Execution__paper.pdf


Understanding if there is any Oauth specific advice to give would be helpful= .   I see there are ways to prevent the SOME exploit.

Regards
John B.


On Jun 24, 2015, at 4:18 PM, Antonio Sa= nso <asa= nso@adobe.com> wrote:

hi *, just sharing.

Not directly related to OAuth per se but it exploits several OAuth client en= dpoints due to some common developers pattern http://www.benhayak.com/2015/06/same-origin-method-execution-some.html (= concrete example in http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.ht= ml)

regards

antonio
_______________________________________________
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo/oauth<= br class=3D"">



--
Nat Sakim= ura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakim= ura.org/
@_nat_en



--
Nat= Sakimura (=3Dnat)
Chairman, OpenID Foundation
= http://nat= .sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
= https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
= OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-EFDD0985-AE75-4927-AC1F-8E3E9D26CA2B-- From nobody Tue Jun 30 05:38:23 2015 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52A31A8BC5 for ; Tue, 30 Jun 2015 05:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 V40uHz4qNeJB for ; Tue, 30 Jun 2015 05:38:15 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 B02071A8BC2 for ; Tue, 30 Jun 2015 05:38:14 -0700 (PDT) Received: by wgjx7 with SMTP id x7so8493449wgj.2 for ; Tue, 30 Jun 2015 05:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0rUZGmldlveLBxrALbaWbcJYWHPLJwjAK6snL5OOGhg=; b=zcFAv3XtD4KSUaFlz/XGwTDu6IzplbErGt4ZihX+uNgS3/KRkdrUsVRYuNKi8xx+KM qW4WJ3Y1Oj3RUJD4u0nTMDJWAM8SOsVizngbm2VSLTCETU3+Ao58IMxJYYE3pQFnQlOl Bx3/inMp9usIdeS/JD9PGsL6SP24DoOHkxlG8hhSAu5KBBX0Ax/J4HJWAE08YgsR9sP/ XHPDMPHM0krB7TwU7p6vCdUlbEml7vnhhpU2FZnepf4RuZd0VfN/bvvkJgvKTFVKQNE5 avlg7UwNp7+JpWYd7O7Fe83VgX2jzNTUkomf0eTnbCEf4llymnVYNld5c9XuChO7IQrU lzdg== X-Received: by 10.180.78.35 with SMTP id y3mr33038791wiw.62.1435667893438; Tue, 30 Jun 2015 05:38:13 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id u7sm16873886wif.3.2015.06.30.05.38.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2015 05:38:12 -0700 (PDT) Message-ID: <55928DB3.7090300@gmail.com> Date: Tue, 30 Jun 2015 13:38:11 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mike Jones , "Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco)" , "OAuth@ietf.org" References: <6B22D19DBF96664DBF49BC7B326402B42739A904@xmb-aln-x09.cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 12:38:20 -0000 Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: "Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B." This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: > That’s what > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. > > Cheers, > > -- Mike > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Vivek Biswas > -T (vibiswas - XORIANT CORPORATION at Cisco) > *Sent:* Thursday, June 25, 2015 2:20 PM > *To:* OAuth@ietf.org > *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case > > Hi All, > > I am looking to solve a use-case similar to WS-Security On-Behalf-Of > > with OAuth JWT Token. > > Is there a standard claim which we can define within the OAuth JWT > which denote the On-behalf-of User. > > For e.g., a Customer Representative trying to create token on behalf of > a customer and trying to execute services specific for that specific > customer. > > Regards, > > Vivek Biswas, > CISSP > > *Cisco Systems, Inc * > > *Bldg. J, San Jose, USA,* > > *Phone: +1 408 527 9176* > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >