Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

"Nat Sakimura" <n-sakimura@nri.co.jp> Wed, 20 January 2016 05:19 UTC

Return-Path: <n-sakimura@nri.co.jp>
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 A53231A21A9 for <oauth@ietfa.amsl.com>; Tue, 19 Jan 2016 21:19:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.608
X-Spam-Level:
X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 C1hKB212Rkcf for <oauth@ietfa.amsl.com>; Tue, 19 Jan 2016 21:19:31 -0800 (PST)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2521A21A8 for <oauth@ietf.org>; Tue, 19 Jan 2016 21:19:31 -0800 (PST)
Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs04.index.or.jp (Postfix) with SMTP id 01831472EDF; Wed, 20 Jan 2016 14:19:31 +0900 (JST)
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp (unknown) with ESMTP id u0K5JUwc013928; Wed, 20 Jan 2016 14:19:30 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0K5JUu3043980; Wed, 20 Jan 2016 14:19:30 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u0K5JUGA043979; Wed, 20 Jan 2016 14:19:30 +0900
X-Authentication-Warning: nrims00b.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 nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0K5JUSu043976; Wed, 20 Jan 2016 14:19:30 +0900
From: "Nat Sakimura" <n-sakimura@nri.co.jp>
To: "'Kepeng Li'" <kepeng.lkp@alibaba-inc.com>, "'Hannes Tschofenig'" <hannes.tschofenig@gmx.net>, <oauth@ietf.org>
References: <569E21DA.30002@gmx.net> <D2C47197.280E1%kepeng.lkp@alibaba-inc.com>
In-Reply-To: <D2C47197.280E1%kepeng.lkp@alibaba-inc.com>
Date: Wed, 20 Jan 2016 14:19:41 +0900
Message-ID: <060901d15342$2a5c1600$7f144200$@nri.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
thread-index: AQGxnaNyUw5Ns5n+891YCYVGabIsJAHI1+PunzUCByA=
Content-Language: ja
X-MailAdviser: 20141126
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/uOFWMFDTqGe5oCX8KMyqF-zTLQg>
Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2016 05:19:33 -0000

Yes from me as well. It could be harmonized better with other PoP proposals,
but the simplicity appeal of this approach is worth considering.
--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.


-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kepeng Li
Sent: Wednesday, January 20, 2016 12:22 AM
To: Hannes Tschofenig; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

> * to make a decision about other extensions. Nat and Kepeng submitted
> the Sender Constrained JWT for OAuth2 2.0 document, see
> https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06
> We asked the working group for feedback during IETF #93 and we
> couldn't get enough feedback at that time. Please give us feedback
> whether you are interested in exploring that solution direction as
> part of this process. Today, we don't have enough indication of
> interest for working on that solution direction.


Yes, I am interested in this solution direction.

Sender Constrained JWT is already indicated in PoP architecture document as
one of the solutions.

If we don’t specify it in detail, the solution set is incomplete.

And there will be interoperability issues when people implement it in
different ways.

Kind Regards
Kepeng

在 19/1/16 7:45 pm, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> 写入:

>Hi all,
>
>I wanted to drop a high level message about possible next steps for the
>PoP work.
>
>As you have seen from my status update, see
>http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the
>PoP architecture document was already in IESG processing but I have had
>asked Kathleen to delay the publication given that we ran into scoping
>issues, as discussed on the list. See
>http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html
>
>The change of scope related to desire to not just binding a key to the
>access token but also to other parts of the OAuth system to avoid cases
>where an attacker can just obtain attack other parts of the system
>instead (for example, by obtaining an bearer-based refresh token to
>then obtain a new PoP access token).
>
>The recently discovered security problems tell us that we need to
>simplify our solutions a bit as well to ensure that we get the security
>analysed properly. More options means more time to analyse all the
>different options.
>
>What does this mean to simplify when I talk about expanding the scope
>in the earlier paragraph?
>
>I am suggesting to
>
>* to consider focusing on a public key-based only solution for the
>web/smart phone app space. (The ACE working group will have to develop
>a symmetric key-based version on their own, if desired.)
>
>* to extend the support of PoP token functionality throughout the
>entire solution. This means that we have to include support for a
>asymmetric version of PKCE into account (which had been discussed in
>the group already earlier already).
>
>* to define at least a TLS-based security security solution for the
>communication between the client and the resource server.
>
>* to rethink the work on the application layer security solution. The
>HTTP signing draft, which defines the application layer security
>solution for use between the client and the resource server, has
>expired and we will have to find new authors. I believe we got stuck a bit.
>Luckily new persons came along and volunteered to help, namely Fredrik
>Ljunggren and Jakob Schlyter. Nevertheless, the group will have to
>judge whether a newly developed application layer security solution is
>promising. My impression is that it is a very difficult to come up with
>a solution that satisfies the security requirements and, at the same
>time, also takes the deployment status of proxies and other middleware
>into account.
>
>* to make a decision about other extensions. Nat and Kepeng submitted
>the Sender Constrained JWT for OAuth2 2.0 document, see
>https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06
>We asked the working group for feedback during IETF #93 and we couldn't
>get enough feedback at that time. Please give us feedback whether you
>are interested in exploring that solution direction as part of this
>process. Today, we don't have enough indication of interest for working
>on that solution direction.
>
>Before making any changes to the PoP document set we would like to hear
>your thoughts.
>
>Ciao
>Hannes
>
>_______________________________________________
>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