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

From: Suresh Kumar Vinapamula Venkata <[email-masked]>
Date: Tue, 7 Jan 2014 04:48:34 +0000

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: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Thu, 9 Jan 2014 06:54:27 +0000

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.

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?

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

4)       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?

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,

---

From: "Anca Zamfir (ancaz)" <[email-masked]>
Date: Wed, 29 Jan 2014 11:25:40 +0000

Hi Tiru et al,
A few comments and questions on this draft.

Section 4:

  *   Figure 1: could you identify the entities you mention in the text below it? Like PCP Client (Alice box), Oauth 2.0 server (does it have to be the WebRTC or could it be separate?)
  *   I don't understand the paragraph after bullet 4 and how is relevant to this section/ draft? What do you mean by "This technique"?

Section 5:

  *   Figure 3: Show a bidirectional Request/ Response on (1). Show a (5) arrow with PCP Response so the loop is closed.
  *   Same question as above. Does the Auth Server has to be the WebRTC Server (or app server in general)? Or is this figure just a possible scenario?
  *   Create section 5.1 for the option detail and say something like "This specification defines the new PCP ACCESS_TOKEN Option…"
  *   Option Length: Is this like any PCP option (i.e. length of Option Data, must be multiple of 4, etc). Maybe just refer to RFC6887 Section 7.3
  *   "Reserved1": set to 0 by sender and ignored by the receiver?
  *   Lifetime: Why does the PCP Client need to tell the PCP Server about the lifetime? Is this the expires_in value that the PCP Client got from the Auth Server? Can this be "extended" later in a PCP Request by the PCP Client/ Alice or Mallory? And what would happen? I thought the PCP Server  must ensure that the token has not expired by interacting with the authorization server (e.g. on arrow (4) in your Figure 3, the Auth server would also include the lifetime). I don't understand why it's needed in the PCP Option.
  *   Timestamp : This assumes some sort of synchronization, right? Then I don't understand how the Timestamp on its own can prevent replay attacks. Maybe you can elaborate on this a bit?
  *   May appear in: response...I don't see any explanation on when PCP Server would include it in response and what is the PCP Client supposed to do/ check. Maybe you can say a few words about this in Sections 5.2 and 5.3
  *   Probably out of scope but what happens on mapping refresh, PCP server restart, etc? Will PCP Client get new token, reuse the old one, etc? Maybe give some hints on good practices?

Section 6:

  *   PCP Proxy question: What are the possible actions here wrt to the TOKEN option? Just forward or drop (e.g. if unknown and configured to drop unknowns)?

thanks,
-anca