Thanks. I will add to the amended draft. Phil
> On Sep 21, 2015, at 16:55, Kepeng Li <[email protected]> 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 <[email protected]> > 日期: Tuesday, 22 September, 2015 1:41 am > 至: Li Kepeng <[email protected]> > 抄送: <[email protected]> > 主题: 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 > [email protected] > >> On Sep 19, 2015, at 9:02 AM, Kepeng Li <[email protected]> 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 <[email protected]> >> ÈÕÆÚ: Saturday, 19 September, 2015 12:55 am >> ÖÁ: <[email protected]> >> Ö÷Ìâ: [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 >> [email protected]https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
