Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

From: [email-masked]
Date: Tue, 24 Nov 2015 12:05:12 -0800

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 Proof-of-Possession (PoP) Security Architecture
        Authors         : Phil Hunt
                          Justin Richer
                          William Mills
                          Prateek Mishra
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-pop-architecture-06.txt
	Pages           : 23
	Date            : 2015-11-24

Abstract:
   The OAuth 2.0 bearer token specification, as defined in RFC 6750,
   allows any party in possession of a bearer token (a "bearer") to get
   access to the associated resources (without demonstrating possession
   of a cryptographic key).  To prevent misuse, bearer tokens must be
   protected from disclosure in transit and at rest.

   Some scenarios demand additional security protection whereby a client
   needs to demonstrate possession of cryptographic keying material when
   accessing a protected resource.  This document motivates the
   development of the OAuth 2.0 proof-of-possession security mechanism.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06

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: Phil Hunt <[email-masked]>
Date: Tue, 24 Nov 2015 12:07:03 -0800

This draft addresses review comments from Kathleen and Erik raised since the last draft.

It may not include some of the discussion from yesterday/today.  I will add that as the group decides.

Cheers,

Phil

@independentid
www.independentid.com
[email-masked]

> On Nov 24, 2015, at 12:05 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 24 Nov 2015 20:44:07 -0500

Thanks, Phil.  Hopefully we can wrap up that discussion soon as well.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Nov 2015 08:30:05 -0700

Looking at the diff I noticed the following new text, which seems to
conflate bearer/PoP and opaqueness to the client. A client demonstrating
proof-of-possession of some key is orthogonal to the client being able to
parse and understand the access token itself.

"In contrast to bearer tokens [RFC6750] which call for tokens that are
opaque to OAuth 2.0 clients, this specification defines the requirements
for proof-of-possession ("PoP") tokens that may be parsed and verified by
OAuth 2.0 clients and relying parties."

-- 
 <https://www.pingidentity.com/>
Brian Campbell
Distinguished Engineer
Ping Identity
@ [email-masked]  +1 720.317.2061 
@pingidentity Connect with us!
<https://www.pingidentity.com/>
<https://www.pingidentity.com/>
<https://ping.force.com/Support/PingIdentityCommunityHome>[image:
pingidentity.com] <https://ping.force.com/Support/PingIdentityCommunityHome>
<http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
twitter logo] <https://twitter.com/pingidentity> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://www.linkedin.com/company/21870> 
<https://www.facebook.com/pingidentitypage> 
<https://plus.google.com/u/0/114266977739397708540> 
<http://www.slideshare.net/PingIdentity> 
<http://flip.it/vjBF7> 
<https://www.pingidentity.com/blogs/>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 25 Nov 2015 07:44:20 -0800

Except that later on we require the token be signed and the client verify that signed token. IOW mutual pop. 

Phil

> On Nov 25, 2015, at 07:30, Brian Campbell <[email-masked]> wrote:
> 
> Looking at the diff I noticed the following new text, which seems to conflate bearer/PoP and opaqueness to the client. A client demonstrating proof-of-possession of some key is orthogonal to the client being able to parse and understand the access token itself. 
>  
> "In contrast to bearer tokens [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, this specification defines the requirements for proof-of-possession ("PoP") tokens that may be parsed and verified by OAuth 2.0 clients and relying parties."
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Nov 2015 10:14:53 -0700

Where does it say that?

On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <[email-masked]> wrote:

> @ [email-masked]  +1 720.317.2061 [image:
> twitter] @pingidentity Connect with us!
> pingidentity.com]
> <https://ping.force.com/Support/PingIdentityCommunityHome>
> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:
> <https://plus.google.com/u/0/114266977739397708540> [image: slideshare
> logo] <http://www.slideshare.net/PingIdentity> 
> <http://flip.it/vjBF7>

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Nov 2015 12:33:26 -0500

The token doesn’t have to be signed and the client doesn’t have to verify the signature on the token. That’s not PoP. The request has to be signed in a way that includes the token. The token itself can still be opaque. The *key* material can’t be opaque to the client, but the *token* material still is.

I agree with Brian that this statement is misleading.

The examples use a signed token but that is absolutely not a requirement. Maybe the examples shouldn’t all use one style.

What’s most difficult about this particular spec is that it’s very hand-wavy, saying “this is kinda a thing that kinda works like this” without saying how to actually do it. I’m honestly not sure it’s worth publishing as an RFC in its own right but I’m not going to stand in its way.

 — Justin

> On Nov 25, 2015, at 12:14 PM, Brian Campbell <[email-masked]> wrote:
> 
> Where does it say that? 
> 
> 
> 
> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> On Nov 25, 2015, at 07:30, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> www.independentid.com <http://www.independentid.com/>
>> [email-masked] <mailto:[email-masked]>
>> 
>> > On Nov 24, 2015, at 12:05 PM, [email-masked] <mailto:[email-masked]> wrote:
>> >
>> >
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/>
>> >
>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06 <https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06>
>> >
>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06>
>> >
>> >
>> > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> >
>> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> >
>> > [email-masked] <mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 
>> -- 
>> @	[email-masked] <mailto:[email-masked]>
>> 	+1 720.317.2061 <tel:%2B1%20720.317.2061>
>> 	@pingidentity
>> Connect with us!
>>  <https://www.pingidentity.com/> <https://www.pingidentity.com/>
>>  <https://ping.force.com/Support/PingIdentityCommunityHome> <https://ping.force.com/Support/PingIdentityCommunityHome> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>  <https://twitter.com/pingidentity>  <https://www.youtube.com/user/PingIdentityTV>  <https://www.linkedin.com/company/21870>  <https://www.facebook.com/pingidentitypage>  <https://plus.google.com/u/0/114266977739397708540>  <http://www.slideshare.net/PingIdentity>  <http://flip.it/vjBF7>  <https://www.pingidentity.com/blogs/>
> 
> 
> -- 
> @	[email-masked] <mailto:[email-masked]>
> 	+1 720.317.2061
> 	@pingidentity
> Connect with us!
>  <https://www.pingidentity.com/> <https://www.pingidentity.com/>
>  <https://ping.force.com/Support/PingIdentityCommunityHome> <https://ping.force.com/Support/PingIdentityCommunityHome> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>  <https://twitter.com/pingidentity>  <https://www.youtube.com/user/PingIdentityTV>  <https://www.linkedin.com/company/21870>  <https://www.facebook.com/pingidentitypage>  <https://plus.google.com/u/0/114266977739397708540>  <http://www.slideshare.net/PingIdentity>  <http://flip.it/vjBF7>  <https://www.pingidentity.com/blogs/>_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Wed, 25 Nov 2015 10:05:49 -0800

Ok. Well this was requested by Kathleen because of this paragraph in Sec 6.…

   To simplify the subsequent description we assume in the PoP architecture
   that the token itself is digitally signed by the authorization server
   and therefore cannot be modified.

Please 
Phil

@independentid
www.independentid.com
[email-masked]

> On Nov 25, 2015, at 9:33 AM, Justin Richer <[email-masked]> wrote:
> 
>> On Nov 25, 2015, at 12:14 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Where does it say that? 
>> 
>> 
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Nov 2015 13:27:22 -0500

Right, I read that as text for describing the examples and not for describing requirements.

The token itself doesn’t have to be signed at all.

 — Justin

> On Nov 25, 2015, at 1:05 PM, Phil Hunt <[email-masked]> wrote:
> 
> www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
>> On Nov 25, 2015, at 9:33 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Nov 2015 18:35:10 +0000

Agreed.  We need to clarify that the token need not be signed, as that's a choice that's orthogonal to PoP.

-- Mike
________________________________
From: Justin Richer<mailto:[email-masked]>
Sent: ‎11/‎25/‎2015 10:27 AM
To: Phil Hunt<mailto:[email-masked]>
Cc: <[email-masked]><mailto:[email-masked]>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

 — Justin

On Nov 25, 2015, at 1:05 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Please
Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On Nov 25, 2015, at 9:33 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 — Justin

On Nov 25, 2015, at 12:14 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Where does it say that?

On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Except that later on we require the token be signed and the client verify that signed token. IOW mutual pop.

Phil

On Nov 25, 2015, at 07:30, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
This draft addresses review comments from Kathleen and Erik raised since the last draft.

Cheers,

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

> On Nov 24, 2015, at 12:05 PM, [email-masked]<mailto:[email-masked]> wrote:
>
>
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
>
> [email-masked]<mailto:[email-masked]>

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

--
[Ping     Identity logo]<https://www.pingidentity.com/>
Brian Campbell
Distinguished Engineer
Ping Identity
@       [email-masked]<mailto:[email-masked]>
[phone] +1 720.317.2061<tel:%2B1%20720.317.2061>
[twitter]       @pingidentity
Connect with us!
<https://www.pingidentity.com/>[pingidentity.com]<https://www.pingidentity.com/>
<https://ping.force.com/Support/PingIdentityCommunityHome>[pingidentity.com]<https://ping.force.com/Support/PingIdentityCommunityHome>
[twitter logo]<http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [twitter logo] <https://twitter.com/pingidentity>  [youtube logo] <https://www.youtube.com/user/PingIdentityTV>  [LinkedIn logo] <https://www.linkedin.com/company/21870>  [Facebook logo] <https://www.facebook.com/pingidentitypage>  [Google+ logo] <https://plus.google.com/u/0/114266977739397708540>  [slideshare logo] <http://www.slideshare.net/PingIdentity>  [flipboard logo] <http://flip.it/vjBF7>  [rss feed icon] <https://www.pingidentity.com/blogs/>

--
[Ping     Identity logo]<https://www.pingidentity.com/>
Brian Campbell
Distinguished Engineer
Ping Identity
@       [email-masked]<mailto:[email-masked]>
[phone] +1 720.317.2061
[twitter]       @pingidentity
Connect with us!
<https://www.pingidentity.com/>[pingidentity.com]<https://www.pingidentity.com/>
<https://ping.force.com/Support/PingIdentityCommunityHome>[pingidentity.com]<https://ping.force.com/Support/PingIdentityCommunityHome>
[twitter logo]<http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [twitter logo] <https://twitter.com/pingidentity>  [youtube logo] <https://www.youtube.com/user/PingIdentityTV>  [LinkedIn logo] <https://www.linkedin.com/company/21870>  [Facebook logo] <https://www.facebook.com/pingidentitypage>  [Google+ logo] <https://plus.google.com/u/0/114266977739397708540>  [slideshare logo] <http://www.slideshare.net/PingIdentity>  [flipboard logo] <http://flip.it/vjBF7>  [rss feed icon] <https://www.pingidentity.com/blogs/>

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

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Nov 2015 11:48:30 -0700

While I can't say I disagree with the deeper existential questions about
the draft that Justin raises, I was trying not to go there and rather just
point out concerns with the newly added text.

The text Phil cites from Sec 6 doesn't say the client must be able to parse
and verify the token. It's an assumption to simplify the examples that
follow and still the token is opaque to the client. I reread the whole
draft (reluctantly) and there's nothing that says the token has to be
non-opaque to the client. And it does talk about reference style tokens and
encrypted tokens, both of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer <[email-masked]> wrote:

> The token doesn’t have to be signed and the client doesn’t have to verify
> the signature on the token. That’s not PoP. The request has to be signed in
> a way that includes the token. The token itself can still be opaque. The
> *key* material can’t be opaque to the client, but the *token* material
> still is.
>
> The examples use a signed token but that is absolutely not a requirement.
> Maybe the examples shouldn’t all use one style.
>
> What’s most difficult about this particular spec is that it’s very
> hand-wavy, saying “this is kinda a thing that kinda works like this”
> without saying how to actually do it. I’m honestly not sure it’s worth
> publishing as an RFC in its own right but I’m not going to stand in its way.
>
>  — Justin
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 25 Nov 2015 11:03:09 -0800

Folks, 

<editor hat>
I did not want to go here either. :-)

I don’t read sec 6 as examples.  I believe this may stem from the pop-architecture documents having a dual role as both “architecture” and “use-case”.  Maybe we should clarify the purpose of the document?

I believe section 6 is talking about threat mitigation assumptions based on the examples that need to be implemented.  I am assuming these are requirements that the other specifications SHOULD implement.

<personal hat>
I do not believe we have discussed Opaque PoP tokens and any inherent risks because the client is not or is unable to validate the authenticity of the token.  Does this introduce the possibility of a MITM attack where a client can be convinced to sign requests for an attacker?

If we want to include opaque PoP, I think we need to take a pause and consider / discuss any threats here.

I find the desire for opaque PoP tokens to be a bit contradictory. If we’re saying we don’t want to trust TLS alone (e.g. because of load-balancer termination), why would we then say, but we are perfectly willing to accept it worked for the OAuth AS exchanges?  Maybe I was very wrong here, but my assumption all along is that for PoP we’re talking about end-to-end authentication of all parties except in the case of 3.3 where we simply want to protect an access token over a non-TLS HTTP connection.

Phil

@independentid
www.independentid.com
[email-masked]

> On Nov 25, 2015, at 10:48 AM, Brian Campbell <[email-masked]> wrote:
> 
> While I can't say I disagree with the deeper existential questions about the draft that Justin raises, I was trying not to go there and rather just point out concerns with the newly added text. 
> 
> The text Phil cites from Sec 6 doesn't say the client must be able to parse and verify the token. It's an assumption to simplify the examples that follow and still the token is opaque to the client. I reread the whole draft (reluctantly) and there's nothing that says the token has to be non-opaque to the client. And it does talk about reference style tokens and encrypted tokens, both of which rely on the opaqueness to the client. 
> 
> On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Nov 25, 2015, at 1:05 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Nov 2015 14:24:20 -0500

It is still end to end authentication with opaque tokens — since all OAuth tokens, including PoP tokens, have always been intended to be opaque to the client. That hasn’t changed and that isn’t the intent of this document. If that’s how people are reading it then we need to pull it back and rewrite it so that’s not the case.

The client gets a token that has two parts: the token and the key. The token is analogous to the access_token we have today and would come out of the server in the same field. The key is handed to the client alongside the token or registered by the client during the token request. Either way there’s an association between the two but it’s not the same association as a public/private keypair. 

It’s possible to sign the token itself, but the client doesn’t care. It sends the token and signs the HTTP request to the RS whether the token is signed, unsigned, hex blob, encrypted, or anything else. The same series of options are available as with bearer tokens. PoP tokens have never, ever been intended to be anything but opaque to the client.

The token can’t be opaque to the RS, which has to figure out what key to use to check the message signature. But we’ve got options there, like the embedded key in a JWT from Mike’s draft, or doing introspection to get the key (from an extension that hasn’t been written yet), or simply looking it up in the same database because the RS and the AS are in the same box. Does this structure/service/database choice sound familiar? It should, it’s the same as bearer tokens. This is also how the RS gets information like which scopes are associated with the token, if it’s expired, and all that. 

So here’s how I see it going on the wire:

(I just wrote this up so there are probably holes. Here’s the source if anyone wants to tweak it: http://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=modern-blue )

The client is oblivious to the token just like always. This is intentional. The RS has the same options to figure out how to process the token.

 — Justin

> On Nov 25, 2015, at 2:03 PM, Phil Hunt <[email-masked]> wrote:
> 
> Folks, 
> 
> <editor hat>
>> On Nov 25, 2015, at 10:48 AM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 25 Nov 2015 11:38:36 -0800

<editors hat>
If there is agreement that tokens are opaque then the requirement that tokens be signed must be removed from the threat mitigation requirements. 

And the paragraph in sec 5 that brian was concerned about be restored. 

Phil

> On Nov 25, 2015, at 11:24, Justin Richer <[email-masked]> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 25 Nov 2015 12:52:01 -0700

My concern was about text that was just *added* to Sec 5 in -06, which just
needs a little fixing up.

I agree with Justin's take on things and think that the document is inline
with that. And is fine for what it is.

No major changes are needed. Just adjust the new text so it's strictly
about the distinction between bearer and pop.

On Wed, Nov 25, 2015 at 12:38 PM, Phil Hunt <[email-masked]> wrote:

> <editors hat>
> If there is agreement that tokens are opaque then the requirement that
> tokens be signed must be removed from the threat mitigation requirements.
>
> It is still end to end authentication with opaque tokens — since all OAuth
> tokens, including PoP tokens, have always been intended to be opaque to the
> client. That hasn’t changed and that isn’t the intent of this document. If
> that’s how people are reading it then we need to pull it back and rewrite
> it so that’s not the case.
>
> The client gets a token that has two parts: the token and the key. The
> token is analogous to the access_token we have today and would come out of
> the server in the same field. The key is handed to the client alongside the
> token or registered by the client during the token request. Either way
> there’s an association between the two but it’s not the same association as
> a public/private keypair.
>
> It’s possible to sign the token itself, but the client doesn’t care. It
> sends the token and signs the HTTP request to the RS whether the token is
> signed, unsigned, hex blob, encrypted, or anything else. The same series of
> options are available as with bearer tokens. PoP tokens have never, ever
> been intended to be anything but opaque to the client.
>
> The token can’t be opaque to the RS, which has to figure out what key to
> use to check the message signature. But we’ve got options there, like the
> embedded key in a JWT from Mike’s draft, or doing introspection to get the
> key (from an extension that hasn’t been written yet), or simply looking it
> up in the same database because the RS and the AS are in the same box. Does
> this structure/service/database choice sound familiar? It should, it’s the
> same as bearer tokens. This is also how the RS gets information like which
> scopes are associated with the token, if it’s expired, and all that.
>
>
>
>
> http://www.websequencediagrams.com/cgi-bin/cdraw?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=modern-blue]
>
>
>
> (I just wrote this up so there are probably holes. Here’s the source if
> anyone wants to tweak it:
> http://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=modern-blue
> )
>
> The client is oblivious to the token just like always. This is
> intentional. The RS has the same options to figure out how to process the
> token.
>
>  — Justin
>
> I don’t read sec 6 as examples.  I believe this may stem from the
> pop-architecture documents having a dual role as both “architecture” and
> “use-case”.  Maybe we should clarify the purpose of the document?
>
> I believe section 6 is talking about threat mitigation assumptions based
> on the examples that need to be implemented.  I am assuming these are
> requirements that the other specifications SHOULD implement.
>
> <personal hat>
> I do not believe we have discussed Opaque PoP tokens and any inherent
> risks because the client is not or is unable to validate the authenticity
> of the token.  Does this introduce the possibility of a MITM attack where a
> client can be convinced to sign requests for an attacker?
>
> I find the desire for opaque PoP tokens to be a bit contradictory. If
> we’re saying we don’t want to trust TLS alone (e.g. because of
> load-balancer termination), why would we then say, but we are perfectly
> willing to accept it worked for the OAuth AS exchanges?  Maybe I was very
> wrong here, but my assumption all along is that for PoP we’re talking about
> end-to-end authentication of all parties except in the case of 3.3 where we
> simply want to protect an access token over a non-TLS HTTP connection.
>
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
> The text Phil cites from Sec 6 doesn't say the client must be able to
> parse and verify the token. It's an assumption to simplify the examples
> that follow and still the token is opaque to the client. I reread the whole
>>> Except that later on we require the token be signed and the client
>>> verify that signed token. IOW mutual pop.
>>>
>>> Phil
>>>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Nov 2015 17:02:10 -0300

The token is opaque to the client.  It’s format is a matter between the RS and the AS. 

Where do we require the client verify the token?    The RS is the only party that needs to verify the access token.

The information that the client needs about the token is in additional meta-data delivered with but not in the AT.

I agree with Brian that is wrong on two counts.

1) the token is opaque to the client.
2) one method of delivering the key to the RS is in a signed JWT.  It is however also possible (if not ideal) for the AT to be a reference, and introspected by the RS to get the key.

So 
"In contrast to bearer tokens [RFC6750] which call for tokens that are opaque to OAuth 2.0 clients, this specification defines the requirements for proof-of-possession ("PoP") tokens that may are also opaque to OAuth 2.0 clients but may be parsed and verified, or introspected by OAuth 2.0 Resource Servers. When token endpoints issue “PoP” tokens they provide the OAuth Client additional parameters with information on what key material to use for the proof.”

Or given that they are both opaque that part of the statement could be dropped.

John B. 

> On Nov 25, 2015, at 12:44 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 25 Nov 2015 12:19:05 -0800

Thats not what I am on about. 

Kathleen objected to the signed requirement in sec 6 without making it clear in sec 5. 

We can't have it both ways. Be both opaque and signed for the client to verify.  

If I restore the requirements than the threat mitigation assumption of signed tokens must also be removed. 

Phil

> On Nov 25, 2015, at 12:02, John Bradley <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Nov 2015 17:20:09 -0300

Tokens are signed or the information is otherwise integrity protected between the AS and the RS.  

I suspect Kathleen is concerned about the key getting modified in transit.   
That needs to be protected against, but there is more than one way to do that.

So sending the public key in a unsigned JWT access token would be immensely stupid,  not just for PoP but for scopes and everything else.

In OAuth 2 all tokens need to be integrity protected between the AS and RS.  
That can be via signature,  by having a reference with sufficient entropy and secure introspection or database lookup.

I think that is a OAuth 2 security consideration.   We are adding a additional confirmation claim to the existing information that needs to be protected the same as the rest.

John B.

> On Nov 25, 2015, at 4:38 PM, Phil Hunt <[email-masked]> wrote:
> 
> <editors hat>
> On Nov 25, 2015, at 11:24, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> (I just wrote this up so there are probably holes. Here’s the source if anyone wants to tweak it: http://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0 <http://www.websequencediagrams.com/?lz=cGFydGljaXBhbnQgQ2xpZW50IGFzIEMKAAwMUmVzb3VyY2UgT3duZXIgYXMgUk8AFA1BdXRob3JpemF0aW9uIFNlcnYAIQZBUwA7DVByb3RlY3RlZABICmFzIFJTCgoKClJPLS0>-QzogR28gZ2V0IG15IHIAbwcKQy0tPlJPOiBSZWRpcmVjdCB0byBBUy9BRQAvBkFTOiBMb2cgaW4sIGEAgQIHZSBjAIFHBQpBUwAqEwAVBwBrCEhhbmQAKQcAPAUgZ3JhbnQKCmFsdCBzAIFGBnN1cHBsaWVkIGtleQpDAG4GVG9rZW4gcmVxdWVzdCAoADAFKQpBUwCBDAZnZW5lcmF0ZSB0ACIFYW4ANwUva2V5cGFpcgAiBUMAPAgmIEsAEAtlbHMAgTcIAE8pICYga2V5AGYYLCBhc3NvY2lhdGUgd2l0aACBQQUAcBIKZW5kCgpDLT5SUzogUgCBUQdpbmNsdWRpbmcAgT4Lc2lnbmVkAEEKAIIkBnRydWN0dXJlZACBbQYKUlMARAZjaGVjawCCAAdzaWduYXR1cmUgLyBkZWNyeXB0AB8PUGFycwCCLgcAOQlVbnBhY2sAgncFAIIYBWludHJvc3BlY3RpbwBiBkFTOiBzZW4AdAcgKG5vdABiCikgdG8AJQ9BAIEVBwAvBWtleSAocHVibGljIG9yIHNoYXJlZCkAgwIGZGF0YWJhc2UAgUUJbG9vayB1cABhCGxvY2FsLwAtBiBEQikAHQthAIQoBgCCUAUAgX4OAIQsCACCBAp1c2luZwCEWAUAGw9pZ2h0cwCDNQoAgm4HAIJbBgCCXQVDOiByZXR1cm4AhicJ&s=modern-blue )
>> 
>>> On Nov 25, 2015, at 2:03 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Folks, 
>>> 
>>> <editor hat>

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Nov 2015 15:21:38 -0500

The only actual requirement is opacity. Section 6 should be more clearly called out as an example instead, which is what it is.

Perhaps we should also re-state that access tokens remain opaque to the client in the introductory text.

 — Justin

> On Nov 25, 2015, at 3:19 PM, Phil Hunt <[email-masked]> wrote:
> 
> On Nov 25, 2015, at 12:02, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> On Nov 25, 2015, at 12:44 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Nov 2015 17:24:45 -0300

The client is verifying the certificate of the token endpoint not the signature of the token.  
That is why It is still vulnerable to man in the middle attacks 

There is no guarantee that the signing key for the AT is one that the client has any way to verify.  
The client checking the signature would not stop a man in the middle attack.

John B.

> On Nov 25, 2015, at 5:19 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Nov 2015 17:31:54 -0300

Yes all access tokens bearer or PoP are audienced to the RS, Integrity protected in a way the RS can verify, and if required encrypted to the RS.

I would guess that a majority of deployments I know of want introspection or encrypted AT to protect the confidentiality of the attributes passed in the access token.
There is commonly user and or role info that they want to protect.   If PoP required the tokens to be readable/verifiable by the client then it would be a non starter for privacy reasons lots of places.

John B.

> On Nov 25, 2015, at 5:21 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Nov 25, 2015, at 3:19 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Nov 2015 15:34:51 -0500

Well not only is it a non-starter, it’s completely unnecessary to begin with. Issues are getting conflated here. I never read that section in the way that it apparently was, so that needs to be backed out.

 — Justin

> On Nov 25, 2015, at 3:31 PM, John Bradley <[email-masked]> wrote:
> 
>> On Nov 25, 2015, at 5:21 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Nov 2015 17:36:44 -0300

The current text of 6 has.
Alternatively, the content of the token could be
   passed by reference rather than by value (requiring a separate
   message exchange to resolve the reference to the token content).

The rest of 6 is an example of using the signed method.  not the only method.

> On Nov 25, 2015, at 5:31 PM, John Bradley <[email-masked]> wrote:
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 25 Nov 2015 15:39:14 -0500

Hi,

Sent from my iPhone

> On Nov 25, 2015, at 3:20 PM, John Bradley <[email-masked]> wrote:
> 

Phil is correct.  I was looking for consistency between the sections since they related to each other.  If there is a security risk or consideration, that needs to be explicitly called out as a concern such as a key being modified in transit.  If there are options to protect against that, those would ideally be required or would have warnings.
> So sending the public key in a unsigned JWT access token would be immensely stupid,  not just for PoP but for scopes and everything else.

Good, easy to require then.

Thanks,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Nov 2015 15:53:44 -0500

The requirement is not that signed JWTs be used, it’s that unsigned JWTs not be used on their own. Reference tokens and encrypted JWTs are also valid, as are other signed formats like SAML assertions or even a COSE Token (if it’s encoded to HTTP friendliness). 

My recommendation:

Remove the erroneous requirement text from section 5 and restore to previous version.

Amend the text in section 6 from:

   To
   simplify the subsequent description we assume in the PoP architecture
   that the token itself is digitally signed by the authorization server
   and therefore cannot be modified.

To:

   In all such cases, the token remains opaque to the client. To
   simplify the subsequent example and description we assume in the PoP architecture
   that the token itself cannot be modified by the client, either due to
   cryptographic protection (such as signature or encryption) or use of 
   a reference value with sufficient entropy and associated secure lookup.
   These are characteristics shared with bearer tokens and more information
   on best practices can be found in [[RFC6819]] and in the security 
   considerations section of [[RFC6750]]. 

 — Justin

> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi,
> 
> Sent from my iPhone
> 
> On Nov 25, 2015, at 3:20 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> On Nov 25, 2015, at 4:38 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> <editors hat>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Nov 2015 17:55:06 -0300

I have been assuming that security considerations from RFC 6750 would be applied to “PoP” tokens as well when the tokens presentment/confirmation specs are done.

Sec 5.2 of RFC 6750 covers mitigations for modification and manufacture for by value and by reference tokens.

Do we want to keep repeating this information in all documents or reference it?

It is fair to say that the threats and mitigations from bearer tokens also apply to PoP tokens.
PoP tokens add additional key information that must also be protected along with the other information in a access token.

John B.

> On Nov 25, 2015, at 5:39 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi,
> 
> Sent from my iPhone
>

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Nov 2015 17:58:33 -0300

I am fine with that, however saying integrity protected, may be better than signed.  May people will argue that HMAC or encryption with sender verification is not signature.
However they are perfectly valid.

> On Nov 25, 2015, at 5:53 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Nov 25, 2015, at 3:39 PM, Kathleen Moriarty <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
>> Sent from my iPhone
>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 25 Nov 2015 17:19:30 -0500

On Wed, Nov 25, 2015 at 3:58 PM, John Bradley <[email-masked]> wrote:

> I am fine with that, however saying integrity protected, may be better
> than signed.  May people will argue that HMAC or encryption with sender
> verification is not signature.
>

Good point, I also prefer integrity protected.  Are we all good with this
now?  I'd like to look at a diff to make sure after following the thread.

Thanks!
Kathleen

> The requirement is not that signed JWTs be used, it’s that unsigned JWTs
> not be used on their own. Reference tokens and encrypted JWTs are also
> valid, as are other signed formats like SAML assertions or even a COSE
> Token (if it’s encoded to HTTP friendliness).
>
> My recommendation:
>
> Phil is correct.  I was looking for consistency between the sections since
> they related to each other.  If there is a security risk or consideration,
> that needs to be explicitly called out as a concern such as a key being
> modified in transit.  If there are options to protect against that, those
> would ideally be required or would have warnings.
>
>
> So sending the public key in a unsigned JWT access token would be
> immensely stupid,  not just for PoP but for scopes and everything else.
>
>
> That can be via signature,  by having a reference with sufficient entropy
> and secure introspection or database lookup.
>
> I think that is a OAuth 2 security consideration.   We are adding a
> additional confirmation claim to the existing information that needs to be
> protected the same as the rest.
>
> John B.
>
>

-- 

Best regards,
Kathleen

---

From: Bill Mills <[email-masked]>
Date: Sat, 28 Nov 2015 07:33:22 +0000 (UTC)

> It is fair to say that the threats and mitigations from bearer tokens also apply to PoP tokens.> PoP tokens add additional key information that must also be protected along with the other > information in a access token.
 THis doesn't really work because for example transport security to protect the token itself is part of the Bearer security considerations and PoP tokens are making that much less of a problem.  I don't know if there's more but that doesn't work.  Referencing specific things from Bearer and not the whole secuiryt considerations section could work.

    On Wednesday, November 25, 2015 12:55 PM, John Bradley <[email-masked]> wrote:

 I have been assuming that security considerations from RFC 6750 would be applied to “PoP” tokens as well when the tokens presentment/confirmation specs are done.
Sec 5.2 of RFC 6750 covers mitigations for modification and manufacture for by value and by reference tokens.
Do we want to keep repeating this information in all documents or reference it?
It is fair to say that the threats and mitigations from bearer tokens also apply to PoP tokens.PoP tokens add additional key information that must also be protected along with the other information in a access token.
John B.

Sent from my iPhone

Tokens are signed or the information is otherwise integrity protected between the AS and the RS.  
I suspect Kathleen is concerned about the key getting modified in transit.   That needs to be protected against, but there is more than one way to do that.

Thanks,Kathleen 

In OAuth 2 all tokens need to be integrity protected between the AS and RS.  That can be via signature,  by having a reference with sufficient entropy and secure introspection or database lookup.
I think that is a OAuth 2 security consideration.   We are adding a additional confirmation claim to the existing information that needs to be protected the same as the rest.
John B.

On Nov 25, 2015, at 4:38 PM, Phil Hunt <[email-masked]> wrote:
<editors hat>If there is agreement that tokens are opaque then the requirement that tokens be signed must be removed from the threat mitigation requirements. 
And the paragraph in sec 5 that brian was concerned about be restored. 
Phil
On Nov 25, 2015, at 11:24, Justin Richer <[email-masked]> wrote:

On Nov 25, 2015, at 2:03 PM, Phil Hunt <[email-masked]> wrote:
Folks, 
<editor hat>I did not want to go here either. :-)
I don’t read sec 6 as examples.  I believe this may stem from the pop-architecture documents having a dual role as both “architecture” and “use-case”.  Maybe we should clarify the purpose of the document?
I believe section 6 is talking about threat mitigation assumptions based on the examples that need to be implemented.  I am assuming these are requirements that the other specifications SHOULD implement.
<personal hat>I do not believe we have discussed Opaque PoP tokens and any inherent risks because the client is not or is unable to validate the authenticity of the token.  Does this introduce the possibility of a MITM attack where a client can be convinced to sign requests for an attacker?
If we want to include opaque PoP, I think we need to take a pause and consider / discuss any threats here.
I find the desire for opaque PoP tokens to be a bit contradictory. If we’re saying we don’t want to trust TLS alone (e.g. because of load-balancer termination), why would we then say, but we are perfectly willing to accept it worked for the OAuth AS exchanges?  Maybe I was very wrong here, but my assumption all along is that for PoP we’re talking about end-to-end authentication of all parties except in the case of 3.3 where we simply want to protect an access token over a non-TLS HTTP connection.

Phil
@[email-masked]

On Nov 25, 2015, at 1:05 PM, Phil Hunt <[email-masked]> wrote:
Ok. Well this was requested by Kathleen because of this paragraph in Sec 6.…
   To simplify the subsequent description we assume in the PoP architecture   that the token itself is digitally signed by the authorization server
   and therefore cannot be modified.

Please Phil
@[email-masked]

Phil

Cheers,

Phil

@independentid
www.independentid.com
[email-masked]

-- 

|    | Brian Campbell
Distinguished Engineer
Ping Identity
| @ | [email-masked] |
|  | +1 720.317.2061 |
|  | @pingidentity |

| Connect with us! |
|          |

 |

-- 

|    | Brian Campbell
Distinguished Engineer
Ping Identity
| @ | [email-masked] |
|  | +1 720.317.2061 |
|  | @pingidentity |

| Connect with us! |
|          |

 |

-- 

|    | Brian Campbell
Distinguished Engineer
Ping Identity
| @ | [email-masked] |
|  | +1 720.317.2061 |
|  | @pingidentity |

| Connect with us! |
|          |

 |