Subject: [OAUTH-WG] AD review of draft-ietf-oauth-pop-architecture

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Nov 2015 15:37:00 -0500

Hello,

I reviewed draft-ietf-oauth-pop-architecture and have a few questions.

1. Section 6, Threat Mitigation:

Last sentence of first paragraph, "To
   simplify the subsequent description we assume that the token itself
   is digitally signed by the authorization server and therefore cannot
   be modified."

Since bearer tokens are not signed by default, is this proposing a
change?  If so, where will that change occur?  To state that "it is
assumed" without it being required anywhere is not a good assumption.
I'd still see this as a risk or security consideration.  When OAuth is
re-used by other protocols, I am seeing that re-use leave off basic
protections that should be assumed like TLS, let alone digital
signatures.  If this is required in the defined architecture (Section
7 - it does show this, but there are no MUSTs that I can find), just
state that and refer to the requirement.

2. Section 6, Threat Mitigation

Third paragraph, "As an example, TLS with a ciphersuite
   that offers confidentiality protection has to be applied (which is
   currently true for all ciphersuites, except for one).

Please list a reference so the reader knows which ciphersuites are
acceptable from the recommended ones in RFC7525.  I don't recall there
being any MTI ciphersuites for OAuth (I'm pretty sure there aren't and
that we've discussed that already with previous drafts, so this should
be spelled out more).

3. (Nit) Section 6.2, add a comma to improve readability
From: "Instead of providing confidentiality protection the authorization
   server could also put the identifier of the client into the protected
   token with the following semantic:"
To: "Instead of providing confidentiality protection, the authorization
   server could also put the identifier of the client into the protected
   token with the following semantic:"

Thank you all for your work on this draft!
-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Tue, 17 Nov 2015 17:06:10 -0800

Just wanted to let everyone know I intend to respond shortly. 

I just got back from some holidays and just clearing my backlog now. 

Cheers

Phil

> On Nov 16, 2015, at 12:37, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Wed, 18 Nov 2015 13:03:33 -0800

Comments inline.

Phil

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

> On Nov 16, 2015, at 12:37 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hello,
> 

[PH] I think the change is the point of the POP specifications. We are talking about a new class of tokens that are specifically not Bearer tokens thus the threat mitigation states that POP tokens are assumed to be digitally signed.

Was that not clear from the introduction?
> that we've discussed that already with previous drafts, so this should
[PH] I think this can be simplified a bit. I think this was referring to a “NULL” ciphersuite which is what 7525 says should not be done.  We should also point to 7525.
>   token with the following semantic:”
> 
[PH] Will add to the next draft pending your comments on the above items.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Nov 2015 11:36:50 -0500

Hi Phil,

Thanks for your response on these questions, a few more comments
in-line and we should be able to wrap this up and move it to the next
phase quickly.

> [PH] I think the change is the point of the POP specifications. We are talking about a new class of tokens that are specifically not Bearer tokens thus the threat mitigation states that POP tokens…

Sure, but that is not spelled out in the requirements section and
should be.  I think the issue may be that the requirements section
just says that the requirements are from RFC4962 and put into OAuth
terms.  There isn't any text or list that says the following
requirements are added for this architecture and I would expect to see
that.  Can you add that so you will be able to make such assumptions
with this architecture going forward and subsequent draft authors
would have clear guidance?

> Was that not clear from the introduction?

There should be something in the requirements section.  The phrasing
of this particular sentence could be changed as follows (in addition
to adding a requirement):

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

Or something like:
    "To
     simplify the subsequent description we assume in this
architecture that the token itself
     is digitally signed by the authorization server and therefore cannot
     be modified."

The second choice is added only because you don't seem to use the term
POP architecture in the draft, but it would be good to make it clear
that this draft adds this assumption, it is something new.

> [PH] I think this can be simplified a bit. I think this was referring to a “NULL” ciphersuite which is what 7525 says should not be done.  We should also point to 7525.

That would take care of it and would be a minor and clear change.  Thank you!

> [PH] Will add to the next draft pending your comments on the above items.

Thank you!
Kathleen

-- 

Best regards,
Kathleen

---

From: Phil Hunt <[email-masked]>
Date: Fri, 20 Nov 2015 09:01:54 -0800

Looks good. (Sorry I missed this in my earlier message). 

I will add to Monday's revision. 

Phil

> On Nov 20, 2015, at 08:36, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Phil,
>