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

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.

On Wed, Nov 18, 2015 at 4:03 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> Comments inline.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>> On Nov 16, 2015, at 12:37 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:
>>
>> 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.
>
> [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.

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.

>>
>> 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).
> [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!

>>
>> 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:”
>>
> [PH] Will add to the next draft pending your comments on the above items.

Thank you!
Kathleen

>
>> Thank you all for your work on this draft!
>> --
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>

-- 

Best regards,
Kathleen