Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt)

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 9 Jan 2014 13:54:42 +0000

Hi Dacheng,

Thanks for review. Please see inline [TR]

From: Zhangdacheng (Dacheng) [mailto:[email-masked]] 
Sent: Thursday, January 09, 2014 12:24 PM
To: Suresh Kumar Vinapamula Venkata; Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati)
Cc: [email-masked]
Subject: RE: Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt)

Hi,

Interesting discussion, I would like to contribute some  comments too:

1) In the security consideration section, maybe it is worthwhile to discuss how to secure the communication between the PCP server and the authorization server. It could be reasonable to assume the communication between the PCP server and the authorization server could be attacked. 

[TR] Yes, the communication between the PCP server and authorization server could be attacked. Therefore the authorization server should issue special credentials to the PCP server so that it can access and query the authorization server.  The communication must also be protected by TLS or equivalent. The actual exchange is outside the scope of this doc. But it's discussed in detail in OAuth WG in draft http://tools.ietf.org/html/draft-richer-oauth-introspection-04. We will describe this attack in the Security Considerations section in the next revision. 

2) In the PCP authentication draft, a PCP Auth session has a life period. What will happen if the session expires before the authorization token the client got from the server expires? 

[TR] If PCP Auth session lifetime expires before the authorization token expires and the PCP client, PCP server fail to trigger re-authentication then dynamic mappings created because of third party authorization should also be deleted.

Since the authorization work and authorization work are compatible, we may also need to consider the scenario where the authorization and EAP authentication are performed concurrently. For instance, is it possible for a PCP client to send the authorization token in the first PCP-Auth message to the PCP server?  Or maybe the token should be sent after the EAP authentication has succeeded. 

[TR] Sending the access token after the EAP authentication has succeeded will give the benefit of integrity protecting the ACCESS_TOKEN option.  we will add a new section in the next revision explaining the usage of PCP third party authz with PCP authentication draft.

3) In addition, in the PCP authentication draft, there is a result code "Authorization Failed", which means the same thing as "AUTHORIZATION_INVALID". Can it be re-used in the authorization work ?

[TR] Yes it can be reused, will update the draft.

Best Regards,
-Tiru.

Cheers

Dacheng

From: pcp [mailto:[email-masked]] On Behalf Of Suresh Kumar Vinapamula Venkata
Sent: Tuesday, January 07, 2014 12:49 PM
To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing); [email-masked]
Cc: [email-masked]
Subject: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt)

Hi Tiru, 

Interesting draft,  here are my initial comments.
1. Why can't we achieve this with http://tools.ietf.org/html/draft-wasserman-pcp-authentication-02 and RFC6887.
2. What is the significance of third party authorization here? There will anyway be admin configuration rules, whether to honor a PCP request from a client or not.
3. How would applications detect that they are behind NAT and they should contact PCP server for opening ports for the data connections?
4. This draft proposes a mechanism where holes are punched in firewall/NAT using PCP as per application thus eliminating the need of ALGs. Is my understanding correct? Applications behind NAT have to use public IP address and port, in the payload so that no pay load translation happens in the NAT box. Wouldn't that not result in rewite of applications and introduce latency? Or, is there another approach? May be a section with migration strategy would be helpful. 
-Suresh

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 13 Jan 2014 06:31:16 +0530

Hi Thiru,

I like this proposal as this mechanism works well for WebRTC scenario
wherein the signaling is not standardized and also, TURN server is not
required. My initial review comments are as follows:

1) Sec 4 Point 2, 3: it has to be OAuth 2.0 Authorization server instead of
OAuth 2.0 server
2) Sec 5 Fig 2, Fig 3: WebRTC server as an authorization server does not
look appropriate to me. As it is possible to have separate authorization
server in the WebRTC scenario.

Thanks
Partha

> -----Original Message-----
> From: pcp [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy
> (tireddy)
> Sent: Thursday, January 09, 2014 7:25 PM
> To: Zhangdacheng (Dacheng); Suresh Kumar Vinapamula Venkata; Reinaldo
> Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati)
> Cc: [email-masked]
> Subject: Re: [pcp] Comments on PCP Extension for Third Party
> Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-
> third-party-authz-01.txt)
> 
> Hi Dacheng,
> 
> To: Suresh Kumar Vinapamula Venkata; Tirumaleswar Reddy (tireddy);
> Reinaldo Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati)
> Cc: [email-masked]
> Subject: RE: Comments on PCP Extension for Third Party Authorization
> (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-
> 01.txt)
> 
> Hi,
> 
> 1) In the security consideration section, maybe it is worthwhile to
> discuss how to secure the communication between the PCP server and the
> authorization server. It could be reasonable to assume the
> communication between the PCP server and the authorization server could
> be attacked.
> 
> [TR] Yes, the communication between the PCP server and authorization
> server could be attacked. Therefore the authorization server should
> issue special credentials to the PCP server so that it can access and
> query the authorization server.  The communication must also be
> protected by TLS or equivalent. The actual exchange is outside the
> scope of this doc. But it's discussed in detail in OAuth WG in draft
> http://tools.ietf.org/html/draft-richer-oauth-introspection-04. We will
> describe this attack in the Security Considerations section in the next
> revision.
> 
> 2) In the PCP authentication draft, a PCP Auth session has a life
> period. What will happen if the session expires before the
> authorization token the client got from the server expires?
> 
> [TR] If PCP Auth session lifetime expires before the authorization
> token expires and the PCP client, PCP server fail to trigger re-
> authentication then dynamic mappings created because of third party
> authorization should also be deleted.
> 
> Since the authorization work and authorization work are compatible, we
> may also need to consider the scenario where the authorization and EAP
> authentication are performed concurrently. For instance, is it possible
> for a PCP client to send the authorization token in the first PCP-Auth
> message to the PCP server?  Or maybe the token should be sent after the
> EAP authentication has succeeded.
> 
> [TR] Sending the access token after the EAP authentication has
> succeeded will give the benefit of integrity protecting the
> ACCESS_TOKEN option.  we will add a new section in the next revision
> explaining the usage of PCP third party authz with PCP authentication
> draft.
> 
> 3) In addition, in the PCP authentication draft, there is a result code
> "Authorization Failed", which means the same thing as
> "AUTHORIZATION_INVALID". Can it be re-used in the authorization work ?
> 
> Subject: [pcp] Comments on PCP Extension for Third Party Authorization
> (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-
> 01.txt)
> 
> Hi Tiru,
> 
> 1. Why can't we achieve this with http://tools.ietf.org/html/draft-
> wasserman-pcp-authentication-02 and RFC6887.
> 2. What is the significance of third party authorization here? There
> will anyway be admin configuration rules, whether to honor a PCP
> request from a client or not.
> 3. How would applications detect that they are behind NAT and they
> should contact PCP server for opening ports for the data connections?
> 4. This draft proposes a mechanism where holes are punched in
> firewall/NAT using PCP as per application thus eliminating the need of
> ALGs. Is my understanding correct? Applications behind NAT have to use
> public IP address and port, in the payload so that no pay load
> translation happens in the NAT box. Wouldn't that not result in rewite
> of applications and introduce latency? Or, is there another approach?
> May be a section with migration strategy would be helpful.
> -Suresh
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp