<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 <jric...@mit.edu> 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: > > > > > > > > (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 <phil.h...@oracle.com> 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 >> phil.h...@oracle.com >> >>> On Nov 25, 2015, at 10:48 AM, Brian Campbell <bcampb...@pingidentity.com> >>> 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 <jric...@mit.edu> 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 <phil.h...@oracle.com> 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 >>>>> phil.h...@oracle.com >>>>> >>>>>> On Nov 25, 2015, at 9:33 AM, Justin Richer <jric...@mit.edu> 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 >>>>>>> <bcampb...@pingidentity.com> wrote: >>>>>>> >>>>>>> Where does it say that? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.h...@oracle.com> >>>>>>>> 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 >>>>>>>>> <bcampb...@pingidentity.com> 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 <phil.h...@oracle.com> >>>>>>>>>> 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 >>>>>>>>>> phil.h...@oracle.com >>>>>>>>>> >>>>>>>>>> > On Nov 24, 2015, at 12:05 PM, internet-dra...@ietf.org 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 >>>>>>>>>> > OAuth@ietf.org >>>>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Brian Campbell >>>>>>>>> Distinguished Engineer >>>>>>>>> Ping Identity >>>>>>>>> @ bcampb...@pingidentity.com >>>>>>>>> +1 720.317.2061 >>>>>>>>> @pingidentity >>>>>>>>> Connect with us! >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Brian Campbell >>>>>>> Distinguished Engineer >>>>>>> Ping Identity >>>>>>> @ bcampb...@pingidentity.com >>>>>>> +1 720.317.2061 >>>>>>> @pingidentity >>>>>>> Connect with us! >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> -- >>> >>> Brian Campbell >>> Distinguished Engineer >>> Ping Identity >>> @ bcampb...@pingidentity.com >>> +1 720.317.2061 >>> @pingidentity >>> Connect with us! >>> >>> >>> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
