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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Jan 2016 12:45:30 +0100

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

---

From: "Kepeng Li" <[email-masked]>
Date: Tue, 19 Jan 2016 23:22:22 +0800

> 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" <[email-masked]> 写入:

>_______________________________________________
>OAuth mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 19 Jan 2016 11:34:18 -0500

Well that’s interesting: I was unaware I was being removed as the author of the HTTP signing draft. This is especially surprising after the presentation I gave at Yokohama about this topic. The draft hasn’t been updated because there’s not really been any discussion on it here in the group to drive an update, and I’m not one to artificially publish a new draft with the same content and a new date just to avoid the “expired” tag in the repository.

To see the direction I proposed that we go in at Yokohama, check my slides here:

https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf <https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf>

Again, I got no real feedback on this and there was no discussion on the list. Even so, I’m implementing this in a Node.js application anyway that I plan to post back to the group here when it’s done.

 — Justin

> On Jan 19, 2016, at 6:45 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "Nat Sakimura" <[email-masked]>
Date: Wed, 20 Jan 2016 14:19:41 +0900

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:[email-masked]] On Behalf Of Kepeng Li
Sent: Wednesday, January 20, 2016 12:22 AM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

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

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

Kind Regards
Kepeng

在 19/1/16 7:45 pm， "Hannes Tschofenig" <[email-masked]> 写入:

>instead (for example, by obtaining an bearer-based refresh token to
>then obtain a new PoP access token).
>
>What does this mean to simplify when I talk about expanding the scope
>in the earlier paragraph?
>
>I am suggesting to
>
>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).
>
>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.
>Ljunggren and Jakob Schlyter. Nevertheless, the group will have to
>judge whether a newly developed application layer security solution is

---

From: "Nat Sakimura" <[email-masked]>
Date: Wed, 20 Jan 2016 14:21:14 +0900

Right. This came as a surprise to me as well. 

Agreed that we need to get more input from HTTP2.0 community etc. but I did not have any impression that Justin has resigned from the editor especially after having seen his presentation in Yokohama. 

Nat Sakimura

--

From: OAuth [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, January 20, 2016 1:34 AM
To: Hannes Tschofenig
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf

 — Justin

On Jan 19, 2016, at 6:45 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]> > wrote:

Hi all,

I am suggesting to

Ciao
Hannes

_______________________________________________
OAuth mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/oauth