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

["Kepeng Li" <[e-mail]>]

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 <http://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