The changes work for me, thanks. On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer <[email protected]> wrote:
> That’s much better. I would also suggest that a few edits to hammer home > that this is an example > > A large range of threats can be mitigated by protecting the content > of the token, for example using a digital signature or a keyed > message digest. 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). To > simplify *discussion in the following example* we assume > 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. *The token > remains opaque to the client.* > > 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]. > > > That’s really what’s going on by my read. Thoughts? > > — Justin > > On Dec 1, 2015, at 1:08 PM, Phil Hunt <[email protected]> wrote: > > I’ve reviewed the comments from John, Justin and Kathleen. As suggested, I > plan to remove the erroneous first paragraph in section 5 (draft 06). > > Combining the comments from this thread about sec 6, here is the proposed > new first paragraph: > > A large range of threats can be mitigated by protecting the content > of the token, for example using a digital signature or a keyed > message digest. 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). To > simplify the subsequent description we assume in the PoP architecture > that the token itself is integrity protected by the authorization > server and the token remains opaque to the client. 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]. > > If this looks good to the group, I’ll post draft 7 this afternoon > (pacific). > > Thanks, > > Phil > > @independentid > www.independentid.com > [email protected] > > On Nov 25, 2015, at 2:19 PM, Kathleen Moriarty < > [email protected]> wrote: > > > > On Wed, Nov 25, 2015 at 3:58 PM, John Bradley <[email protected]> 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 > > > >> However they are perfectly valid. >> >> >> On Nov 25, 2015, at 5:53 PM, Justin Richer <[email protected]> wrote: >> >> 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 protected]> wrote: >> >> Hi, >> >> Sent from my iPhone >> >> On Nov 25, 2015, at 3:20 PM, John Bradley <[email protected]> wrote: >> >> 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. >> >> >> 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 >> >> >> 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 protected]> 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 protected]> wrote: >> >> 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: >> >> >> >> [image: >> 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 >> >> On Nov 25, 2015, at 2:03 PM, Phil Hunt <[email protected]> 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 >> >> @independentid >> www.independentid.com >> [email protected] >> >> On Nov 25, 2015, at 10:48 AM, Brian Campbell <[email protected]> >> 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 protected]> wrote: >> >>> 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 protected]> 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 >>> >>> @independentid >>> www.independentid.com >>> [email protected] >>> >>> On Nov 25, 2015, at 9:33 AM, Justin Richer <[email protected]> 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. >>> >>> 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 protected]> >>> wrote: >>> >>> Where does it say that? >>> >>> >>> >>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <[email protected]> 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 protected]> >>>> 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." >>>> >>>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <[email protected]> >>>> wrote: >>>> >>>>> 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 protected] >>>>> >>>>> > On Nov 24, 2015, at 12:05 PM, [email protected] wrote: >>>>> > >>>>> > >>>>> > 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/ >>>>> > >>>>> > _______________________________________________ >>>>> > OAuth mailing list >>>>> > [email protected] >>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> >>>> -- >>>> [image: Ping Identity logo] <https://www.pingidentity.com/> >>>> Brian Campbell >>>> Distinguished Engineer >>>> Ping Identity >>>> @ [email protected] [image: phone] +1 720.317.2061 [image: >>>> twitter] @pingidentity Connect with us! >>>> <https://www.pingidentity.com/>[image: pingidentity.com] >>>> <https://www.pingidentity.com/> >>>> <https://ping.force.com/Support/PingIdentityCommunityHome>[image: >>>> pingidentity.com] >>>> <https://ping.force.com/Support/PingIdentityCommunityHome> >>>> [image: twitter logo] >>>> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> >>>> [image: >>>> twitter logo] <https://twitter.com/pingidentity> [image: youtube logo] >>>> <https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo] >>>> <https://www.linkedin.com/company/21870> [image: Facebook logo] >>>> <https://www.facebook.com/pingidentitypage> [image: Google+ logo] >>>> <https://plus.google.com/u/0/114266977739397708540> [image: slideshare >>>> logo] <http://www.slideshare.net/PingIdentity> [image: flipboard logo] >>>> <http://flip.it/vjBF7> [image: rss feed icon] >>>> <https://www.pingidentity.com/blogs/> >>>> >>>> >>> >>> >>> -- >>> [image: Ping Identity logo] <https://www.pingidentity.com/> >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ [email protected] [image: phone] +1 720.317.2061 [image: >>> twitter] @pingidentity Connect with us! >>> <https://www.pingidentity.com/>[image: pingidentity.com] >>> <https://www.pingidentity.com/> >>> <https://ping.force.com/Support/PingIdentityCommunityHome>[image: >>> pingidentity.com] >>> <https://ping.force.com/Support/PingIdentityCommunityHome> >>> [image: twitter logo] >>> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> >>> [image: >>> twitter logo] <https://twitter.com/pingidentity> [image: youtube logo] >>> <https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo] >>> <https://www.linkedin.com/company/21870> [image: Facebook logo] >>> <https://www.facebook.com/pingidentitypage> [image: Google+ logo] >>> <https://plus.google.com/u/0/114266977739397708540> [image: slideshare >>> logo] <http://www.slideshare.net/PingIdentity> [image: flipboard logo] >>> <http://flip.it/vjBF7> [image: rss feed icon] >>> <https://www.pingidentity.com/blogs/> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >> >> >> -- >> [image: Ping Identity logo] <https://www.pingidentity.com/> >> Brian Campbell >> Distinguished Engineer >> Ping Identity >> @ [email protected] [image: phone] +1 720.317.2061 [image: >> twitter] @pingidentity Connect with us! >> <https://www.pingidentity.com/>[image: pingidentity.com] >> <https://www.pingidentity.com/> >> <https://ping.force.com/Support/PingIdentityCommunityHome>[image: >> pingidentity.com] >> <https://ping.force.com/Support/PingIdentityCommunityHome> >> [image: twitter logo] >> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> >> [image: >> twitter logo] <https://twitter.com/pingidentity> [image: youtube logo] >> <https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo] >> <https://www.linkedin.com/company/21870> [image: Facebook logo] >> <https://www.facebook.com/pingidentitypage> [image: Google+ logo] >> <https://plus.google.com/u/0/114266977739397708540> [image: slideshare >> logo] <http://www.slideshare.net/PingIdentity> [image: flipboard logo] >> <http://flip.it/vjBF7> [image: rss feed icon] >> <https://www.pingidentity.com/blogs/> >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > > > -- > > Best regards, > Kathleen > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > -- Best regards, Kathleen
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
