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

From: "Kepeng Li" <[email-masked]>
Date: Sun, 20 Sep 2015 00:02:38 +0800

Additional comments:

6. Section 4:
1) An attacker may generate a bogus tokens …
[Kepeng] Change “tokens” to “token”.
 
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. 
 
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”.
 
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.
 
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”.
 
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.
 
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?
 
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”?

Kind Regards
Kepeng

发件人:  Li Kepeng <[email-masked]>
日期:  Saturday, 19 September, 2015 12:55 am
至:  <[email-masked]>
主题:  [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?

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.
 
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?
 
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”?
 
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”?
 
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”?

Kind Regards
Kepeng
_______________________________________________ OAuth mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Sat, 19 Sep 2015 12:32:32 -0700

Thanks Kepeng for the review. I will respond next week. 

Cheers,

Phil

> On Sep 19, 2015, at 09:02, Kepeng Li <[email-masked]> wrote:
> 
> Additional comments:
> 
> 6. Section 4:
> [Kepeng] Change “re-use” to “reuse”. The pragraph title says “reuse”. Also in other places.
>  
> 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”.
>  
> 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.
>  
> 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] 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.
>  
> 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?
>  
> 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”?
> 
> Kind Regards
> Kepeng
> 
> 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?
>  
> 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.
>  
> 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. 
> 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.
> First, an eavesdropper may steal an access token and represent it at a different resource server.
> 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.
> _______________________________________________ OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Sep 2015 10:41:45 -0700

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-masked]

> On Sep 19, 2015, at 9:02 AM, Kepeng Li <[email-masked]> wrote:
> 
> Additional comments:
> 
> 6. Section 4:
[ph] Agreed.
> [Kepeng] Change “re-use” to “reuse”. The pragraph title says “reuse”. Also in other places.
[ph] Agreed
> [Kepeng] Change “the first examples borrow” to “the first example is borrowed”.
[PH] Agreed.
> [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.

> [Kepeng] Change “due” to “due to”.
[ph] Sec 5.4 Sender Constraints.  Agreed.
> [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)
> 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.

> [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-masked] <mailto:[email-masked]>>
> ÈÕÆÚ: Saturday, 19 September, 2015 12:55 am
> ÖÁ: <[email-masked] <mailto:[email-masked]>>
> Ö÷Ìâ: [OAUTH-WG] Review comments to PoP Architecture
> 
> Hello authors,
> 
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02 <https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02>
> 
> 1.     Introduction:

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

> [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…

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

> [Kepeng] Change “is conveyed” to “should be conveyed”?
[ph] Agreed (last para of Sec 3.2)
> [Kepeng] Change “represent it at” to “present it to”?
[ph] Agreed.
> [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-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: "Kepeng Li" <[email-masked]>
Date: Tue, 22 Sep 2015 07:55:54 +0800

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-masked]>
日期:  Tuesday, 22 September, 2015 1:41 am
至:  Li Kepeng <[email-masked]>
抄送:  <[email-masked]>
主题:  Re: [OAUTH-WG] Review comments to PoP Architecture

Kepeng,

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>
[email-masked]

[ph] Agreed.
[ph] Agreed
[PH] Agreed.
[ph]

PROPOSED TEXT:

> there may be additional challenges due Web server load balancing, lack of API
> access to identity information, etc.

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

> [Kepeng] What is “an unauthorized authorized”? Should it be “an unauthorized
[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:

> 
> Kind Regards
> Kepeng
> 
> ·¢¼þÈË:  Li Kepeng <[email-masked]>
> ÖÁ:  <[email-masked]>
> 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.

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

> desire of resource servers to obtain additional assurance that   the client is
> indeed authorized to present an access token.
[PH]
PROPOSED TEXT:

[PH] 
ORIGINAL:

PROPOSED TEXT:

>  
> 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.
[ph] Agreed.
[ph]
ORIGINAL:

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.

> [email-masked]://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Sep 2015 22:15:36 -0700

Thanks. I will add to the amended draft. 

Phil

> On Sep 21, 2015, at 16:55, Kepeng Li <[email-masked]> wrote:
> 
>> _______________________________________________ OAuth mailing list [email-masked]://www.ietf.org/mailman/listinfo/oauth