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

Thanks, guys. If we are all okay, I'll start the last call once the new draft is posted. I need to get them started by sometime tomorrow to keep them on the telechat in 2 weeks. Thanks, Kathleen On Tue, Dec 1, 2015 at 5:28 PM, John Bradley wrote: > That looks good to me. > > On Dec 1, 2015, a

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

That looks good to me. > On Dec 1, 2015, at 4:21 PM, Justin Richer wrote: > > You’ve got “The token remains opaque to the client” in there twice now. I had > cut out the middle part the first sentence in the second paragraph below, but > that was hard to highlight. If you take my text as-is th

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

This is my proposal: 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 messa

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

Justin, I was wondering why you put in the second sentence in bold. :-) I’m not sure which one you want to take out. Would you post the text exactly as you would like it? Thanks, Phil @independentid www.independentid.com phil.h...@oracle.com > On Dec 1, 2015, at 11:21 AM, Justin Richer wrot

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

You’ve got “The token remains opaque to the client” in there twice now. I had cut out the middle part the first sentence in the second paragraph below, but that was hard to highlight. If you take my text as-is that’s what I meant for the edited form. Thanks — Justin > On Dec 1, 2015, at 2:18

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

Including Justin’s revision: 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 separat

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

Thanks Justin. Your tweaks look good to me. Phil @independentid www.independentid.com phil.h...@oracle.com > On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty > wrote: > > The changes work for me, thanks. > > On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer > wrote: > That

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

The changes work for me, thanks. On Tue, Dec 1, 2015 at 1:27 PM, Justin Richer 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

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

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

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

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 protectin

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

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

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

On Wed, Nov 25, 2015 at 3:58 PM, John Bradley 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 go

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

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 wrote: > > The requirement is not that s

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

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 rep

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

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 er

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

Hi, Sent from my iPhone > On Nov 25, 2015, at 3:20 PM, John Bradley 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 ag

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

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

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

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 wrote: > > Yes all access tokens

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

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 t

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

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

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

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 wrote: >

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

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

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

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 al

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

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

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

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

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

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 wrote: > > It is still end

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

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 rewr

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

Folks, 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 threa

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

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 a

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

<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt 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

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

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 wrote: > > Ok. Well this was requested by Kathleen because of this paragraph in Sec 6.… > >To

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

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

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

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 st

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

Where does it say that? On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt 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 > wrote: > > Looking at the diff I noticed the foll

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

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 wrote: > > Looking at the diff I noticed the following new text, which seems to conflate > bearer/PoP and opaqueness to the client. A

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

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 [RFC67

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

Thanks, Phil. Hopefully we can wrap up that discussion soon as well. Best regards, Kathleen On Tue, Nov 24, 2015 at 3:07 PM, Phil Hunt wrote: > This draft addresses review comments from Kathleen and Erik raised since the > last draft. > > It may not include some of the discussion from yesterda

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

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 P

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

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