Re: [OAUTH-WG] Review comments to PoP Architecture

[Phil Hunt <[e-mail]>]

Thanks. I will add to the amended draft. 

Phil

> On Sep 21, 2015, at 16:55, Kepeng Li <[e-mail]> wrote:
> 
> Phil, thanks for the response.
> 
> A typo, about comment 3, „than" should be „then“. Others are fine with me.
> 
> PROPOSED TEXT:
> In a scenario where a resource server receives a valid access token, 
> the resource server than then re-uses it with other resource server. 
> 
> Kind Regards
> Kepeng
> 
> 发件人: Phil Hunt <[e-mail]>
> 日期: Tuesday, 22 September, 2015 1:41 am
> 至: Li Kepeng <[e-mail]>
> 抄送: <[e-mail]>
> 主题: Re: [OAUTH-WG] Review comments to PoP Architecture
> 
> Kepeng,
> 
> Kepeng, thanks for the review!
> 
> My responses (to both emails) to are contained in this message prefixed with [ph] below.
> 
> Pending further comments from the WG over the next day or so, I will post a revision early Wednesday (pacific time).
> 
> I would like to draw the WG’s attention to my recommendation for Section 7, comment 2. I’m not sure if I have the definition correct yet. It still seems awkward to me.
> 
> Thanks,
> 
> Phil
> 
> @independentid
> www.independentid.com
> [e-mail]
> 
>> On Sep 19, 2015, at 9:02 AM, Kepeng Li <[e-mail]> wrote:
>> 
>> Additional comments:
>> 
>> 6. Section 4:
>> 1) An attacker may generate a bogus tokens …
>> [Kepeng] Change “tokens” to “token”.
> [ph] Agreed.
>>  
>> 2) A client may also re-use access tokens for some other resource servers.
>> [Kepeng] Change “re-use” to “reuse”. The pragraph title says “reuse”. Also in other places.
> [ph] Agreed
>>  
>> 3) To illustrate key confirmation the first examples borrow from Kerberos and use symmetric key cryptography.
>> [Kepeng] Change “the first examples borrow” to “the first example is borrowed”.
> [PH] Agreed.
>>  
>> 7. Section 5.4
>> 1) As a high level message, there are various ways how the threats can be mitigated and while the details of each solution is somewhat different they all ultimately accomplish the goal.
>> [Kepeng] Change the last sentence to: the details of each solution are somewhat different even they all can ultimately accomplish the goal.
> [ph]
> 
> PROPOSED TEXT:
> As a high level message, there are various ways the threats can
>    be mitigated. While the details of each solution are somewhat
>    different, they all accomplish the goal of mitigating the threats.
> 
>>  
>> 2) Depending on the chosen layer for providing client-side authentication there may be additional challenges due Web server load balancing, lack of API access to identity information, etc.
>> [Kepeng] Change “due” to “due to”.
> [ph] Sec 5.4 Sender Constraints.  Agreed.
>>  
>> 8. Section 6:
>> [Kepeng] It will be better if we can divide this section into several sub-sections, e.g. each sub-section can be related to each figure.
> 
> broke into the following sub-sections:
> 
> * Client and Authorization Server Interaction
>  ** Symmetric Keys
>  ** Asymmetric Keys
> * Client and Resource Server Interaction
> * Resource and Authorization Server Interaction (Token Introspection)
>>  
>> 9. Section 7:
>> 1) [Kepeng] Usually the order for a specification is: use cases, requirements, then architecture. Why do we have requirements after architecture? Should we move this section ahead?
> [ph] Agreed.  Will move ahead of “Threat Mitigation” and after “Security and Privacy Threats” section.
> 
>>  
>> 2) The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authorized is detected.
>> [Kepeng] What is “an unauthorized authorized”? Should it be “an unauthorized access”?
> [ph]  I’m not sure I captured the WG’s intent here. Can someone suggest a better explanation for Authorization?
> ORIGINAL:
>       Client and resource server authorization MUST be performed.  These
>       entities MUST demonstrate possession of the appropriate keying
>       material, without disclosing it.  Authorization is REQUIRED
>       whenever a client interacts with an authorization server.  The
>       authorization checking prevents an elevation of privilege attack,
>       and it ensures that an unauthorized authorized is detected.
> 
> PROPOSED:
>       Client and resource server authorization MUST be performed.  These
>       entities MUST demonstrate possession of the appropriate keying
>       material, without disclosing it.  Authorization is REQUIRED
>       whenever a client interacts with an authorization server.  
>       Authorization checking prevents an elevation of privilege attack.
> 
>> 
>> Kind Regards
>> Kepeng
>> 
>> ·¢¼þÈË: Li Kepeng <[e-mail]>
>> ÈÕÆÚ: Saturday, 19 September, 2015 12:55 am
>> ÖÁ: <[e-mail]>
>> Ö÷Ìâ: [OAUTH-WG] Review comments to PoP Architecture
>> 
>> Hello authors,
>> 
>> Please find my review comments to PoP Architecture document:
>> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02
>> 
>> 1.     Introduction:
>> At the time of writing the OAuth 2.0 protocol family ([RFC6749],    [RFC6750], and [RFC6819]) offer a single standardized security mechanism to access protected resources, namely the bearer token.
>> [Kepeng]  This sentences seem to be incomplete. What offers a security mechanism? Also why do we mention “at the time of writing”? Is the situation changed now?
> 
> [PH] Agreed.
> 
> PROPOSED TEXT:
> The OAuth 2.0 protocol family ([RFC6749], [RFC6750], and [RFC6819
> ]) offer a single token type known as the “bearer” token to access protected resources.
> 
>>  
>> 2. Section 3:
>> The main use case that motivates better-than-bearer token security is    the desire of resource servers to obtain additional assurance that    the client is indeed authorized to present an access token.
>> [Kepeng] About “better-than-bear”, is it a word? Maybe reword the sentence a little bit.
> [PH]
> PROPOSED TEXT:
> The main use case that motivates improvement upon “bearer” tokens is…
> 
>>  
>> 3.Section 3.1
>> 1) In a legitimate use case consider chaining of computations whereby a resource server needs to consult other third party resource servers to complete the requested operation. 
>> [Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit?
> [PH] 
> ORIGINAL:
> Imagine a scenario where a resource server that receives a valid
>    access token re-uses it with other resource server.  The reason for
>    re-use may be malicious or may well be legitimate.  In a legitimate
> use case consider chaining of computations whereby a resource server
>    needs to consult other third party resource servers to complete the
>    requested operation.
> 
> PROPOSED TEXT:
> In a scenario where a resource server receives a valid access token, 
> the resource server than re-uses it with other resource server.  The 
> reason for re-use may be malicious or may well be legitimate.  In a 
> legitimate case, the intent is to support chaining of computations 
> whereby a resource server needs to consult other third party resource 
> servers to complete a requested operation.  
> 
> 
>>  
>> 2) In this use case additional information is conveyed to the resource server to ensure that no entity entity has tampered with the TLS connection.
>> [Kepeng] Change “is conveyed” to “should be conveyed”?
> [ph] Agreed (last para of Sec 3.2)
>>  
>> 4. Section 3.3:
>> First, an eavesdropper may steal an access token and represent it at a different resource server.
>> [Kepeng] Change “represent it at” to “present it to”?
> [ph] Agreed.
>>  
>> 5. Section 3.4:
>> These load balancers may terminate the TLS connection setup and HTTP traffic is transmitted in the clear from the load balancer to the resource server.
>> [Kepeng] Don’t understand “in the clear”. Should it be “in the wire”?
> [ph]
> ORIGINAL:
> These load balancers may terminate the TLS
>    connection setup and HTTP traffic is transmitted in the clear from
>    the load balancer to the resource server.
> 
> PROPOSED TEXT:
> These load balancers may terminate the TLS
>    connection setup and HTTP traffic is transmitted without TLS protection from
>    the load balancer to the resource server.
> 
>> 
>> Kind Regards
>> Kepeng
>> _______________________________________________ OAuth mailing list [e-mail]://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>