Hi, Sent from my iPhone
> On Nov 25, 2015, at 3:20 PM, John Bradley <ve7...@ve7jtb.com> 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 <phil.h...@oracle.com> 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 <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 > > _______________________________________________ > 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
