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

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 04 February 2016 19:17 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 9F45F1ACDE7 for <oauth@ietfa.amsl.com>; Thu, 4 Feb 2016 11:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.151
X-Spam-Level:
X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 KD4_czKLHkMc for <oauth@ietfa.amsl.com>; Thu, 4 Feb 2016 11:17:26 -0800 (PST)
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 6D57D1ACD30 for <oauth@ietf.org>; Thu, 4 Feb 2016 11:17:25 -0800 (PST)
Received: from [192.168.10.140] ([80.92.118.18]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MIuft-1aTLD33sU5-002UZX; Thu, 04 Feb 2016 20:17:17 +0100
To: Kepeng Li <kepeng.lkp@alibaba-inc.com>, "oauth@ietf.org" <oauth@ietf.org>
References: <569E21DA.30002@gmx.net> <D2C47197.280E1%kepeng.lkp@alibaba-inc.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <56B3A3BA.9090304@gmx.net>
Date: Thu, 4 Feb 2016 20:17:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <D2C47197.280E1%kepeng.lkp@alibaba-inc.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4CfOHDfDfMFbLxn5JjTaGQW2DRo5o19bP"
X-Provags-ID: V03:K0:y/wlnQYZ4LRC1H0R0MPaabuwGS+atKtsYceJ4og4JxbY81ckRpE OYvzXKa5zir80QZwDCdskOG8JPfGBcUF7AO3GImukb1YGfjkbpMtF0ZWinpgvIJN3IUV4LP cfOWvVe+dsxaMpH0qwEFpL7oH1SL3aoQJeydSd37xF0PnR9dxtgaCJ1XK/X07NKekILtMHa poDe9KVfJzfHwH9kbK51g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:dSzOzNnDEGQ=:Rqo0exD5XhDtTa5GtK14xG xwzxKCb8KRM0TD/sp6F0xOmDa3MeOB38i45D+KD6cw2nb80GAJh0TVhVubVkw4DfRqaHPKEK3 q3cj8MAFiZIGUkwAunLYqO+mrDs9EfcSA5RYjWESoZ78YeKvp/ZQtEvki7lp+SrNo8Rr/THyi 1iFwrBxgjFGruahqae5cz2w5Z7giqLouC3EGgifrjNvy13x4g1XUcZwLwtluKIbmDqZXGla2c w5m1elrERQvHVlMqQglD4S8v83Q76TXdWKuipzAHWeJgyI8XEaLOzOARGXXb5tMpPUgLbdngw C/mgktT7Vbe+b3pQyQHhL0WnLtL7wK3B/8/O5Lz4sYYIICXjX14BSlollPsVF/tcYMXMDpjsJ Bv1+SOi0hLndAWWqLZovemMmc9Gnf3xwEn1qWQdcDtSyzWJ9eDsTfwwx/lbZ3Hv4SYVuPTF/9 Y21YXBaduEz6njcN51LXRmrnVRqRYWDEJrrPrDubdQ154d9ixu6JPLsksVKmjgRdZ0RTKCQdF 3d6OG3aRw5t7vQIJWeTtI2i6XJQpP02m16TuvFNDabhXAGgeYqK0CJdqffuuhbQHVseZvf3eG 7RL3T0h6rc6/qu0JikmxGKcGPsKHfdpdFKK1wO1Z8IbiR8LHIIYeIH/XWhI5VT2I6c8HNtqeJ WlsyokwDoJVw2xtdzTC3T0yPNtJ9g5vVvKVxXsqSjs2Og2GG/0jrlSfoHQVfAdzeb3x9taRNl owPqAuwPYXrDIwlFfz+oY16J+o9TQZQMG2uWO9t0+7pI3L0PxZF0cZ9LWuA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/n_0Z1QUgscKptcudPNX5yKrp2Sk>
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: Thu, 04 Feb 2016 19:17:27 -0000

Hi Kepeng,

thanks for your input.

> Yes, I am interested in this solution direction.
> 
> Sender Constrained JWT is already indicated in PoP architecture document
> as one of the solutions.

That is correct.

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

That's unfortunately wrong. The Sender Constrained JWT is one solution
that essentially provides the same functionality to the PoP token.

> 
> And there will be interoperability issues when people implement it in
> different ways.
That's correct. However, the group decided to go on a different route,
namely the PoP token route and if we can reduce the number of options
that people use to implement the same functionality then that's actually
better in the long run.

Ciao
Hannes

> 
> 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
> 
>