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: Mon, 13 Jan 2014 09:23:50 +0000

Hi Suresh,

Please see line

> -----Original Message-----
> From: Suresh Kumar Vinapamula Venkata [mailto:[email-masked]]
> Sent: Saturday, January 11, 2014 7:09 AM
> To: 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)
> 
> Few followup questions. Please see inline.
> 
> On 1/9/14 1:38 AM, "Tirumaleswar Reddy (tireddy)" <[email-masked]>
> wrote:
> 
> >Hi Suresh,
> >
> >Thanks for the review. Please see inline
> >
> >From: Suresh Kumar Vinapamula Venkata [mailto:[email-masked]]
> >Sent: Tuesday, January 07, 2014 10:19 AM
> >To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing
> >(dwing); Prashanth Patil (praspati)
> >Cc: [email-masked]
> >Subject: Comments on PCP Extension for Third Party Authorization
> >(http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-0
> >1.t
> >xt)
> >
> >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.
> >
> >[TR] RFC 6887 does not have any mutual authentication mechanism
> between
> >the PCP client and PCP server, hence draft-ietf-pcp-authentication-02
> >is introduced.  draft-ietf-pcp-authentication-02 solves first party
> >auth problem.
> >
> >Third party authorization would be required in scenarios where PCP
> >client does have not have authorization to use specific PCP opcodes,
> >but will get temporary authorization from an application server (e.g.
> >WebRTC
> >Server) trusted by the Network. This requirement (REQ-13) is discussed
> >in http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04.
> SV> I don't see REQ-13 in the draft
> http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04.

It's specified in section 4 of the draft http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04#section-4. 

> 
> >
> >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.
> >
> >[TR] Admin configuration rules are static. With PCP third party
> >authorization clients will get time-bound, dynamic permission to send
> >PCP requests to PCP Server.
> SV> Who and on what basis will give this authorization? You mean
> Application server?
> >
> >3. How would applications detect that they are behind NAT and they
> >should contact PCP server for opening ports for the data connections ?
> >
> >[TR] PCP client can use techniques like draft-ietf-pcp-dhcp to find the
> >PCP Servers in the network.  PCP Servers would be available if
> >PCP-aware NAT or firewall exists. By using PCP MAP/PEER opcodes or by
> >using any other mechanism like STUN, client can find out if it is behind NAT
> or not.
> >
> >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?
> >
> >[TR] No, that's the goal of PCP itself, not this draft.
> SV> Correct. But, abstract of this draft talks necessity of opening
> SV> ports
> and weakness with algs. So, I initially assumed it is meant for any existing
> application. So was asking for the migration path. Looks like in addition to
> applications, there has to be a signaling and an oauth server, which issues
> tokens on need basis to its clients for them to raise PCP requests. Is that
> correct ?

Yes. WebRTC does not mandate any specific signaling protocol, so the proprietary signaling protocol used by the web provider can be enhanced to provide the tokens to the client (Java Script). The Java Script can use the PCP client provided by the browser  to send PCP request with ACCESS_TOKEN option to the PCP Server. For example PCP implementation by Mozilla is discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=845007.  The WebRTC Server itself is acting as Authorization server.

> What is the communication channel between signaling server and oauth
> server ? 
> Before that, are they the same are different? 

Yes, the signaling server and authorization server are the same. 

> In other words, is
> application issued token only when the signaling server detect the need ?

Yes

> 
> >
> >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.
> >
> >[TR] With or without third party authorization with PCP, applications
> >will have to rewritten to use public IP address and port learnt from
> >PCP MAP response.
> >Third party authorization is assisting applications to be deployed in
> >networks with restrictive firewall policies. For example a PCP-aware
> >firewall with a restrictive policy to permit media streams only when
> >call is made using WebRTC/SIP Server trusted by the Enterprise network
> >can use the technique proposed in this draft to open/close firewall
> >mapping thus eliminating the need of ALGs.
> >This way media streams will not permitted if the clients use unknown
> >WebRTC/SIP Servers to make a call.
> SV> What if an application granted a token to raise a PEER request, but
> raises a MAP request ?

To validate the handle token, PCP server will communicate with the authorization server and can identify the grant (i.e. PCP requests the client is permitted to use). Handle Token validation for other use cases is already implemented by vendors like PingIdentity (http://documentation.pingidentity.com/display/PF66/Token+Models) and the protocol they had used for token validation is discussed in Oauth WG thread http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html. The work to standardize the communication is discussed in http://tools.ietf.org/html/draft-richer-oauth-introspection-04

> 
> SV>If bob is in same network as alice, then you expect hair pin
> communication or direct communication between alice or bob, it is left to
> application signaling server's discretion ?

The application signaling server could be located in the cloud or provided by third party that Enterprise has tie-up with. It may not be aware where alice, bob are located.  

-Tiru.
> >-Tiru.
> >-Suresh

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 13 Jan 2014 12:45:30 +0000

Hi Partha,

> From: Parthasarathi R [mailto:[email-masked]]
> Sent: Monday, January 13, 2014 6:31 AM
> To: Tirumaleswar Reddy (tireddy); '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
> 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

Yes, updated the draft.

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

The Authorization server has to be WebRTC signaling server because only it will be aware of call termination details to revoke the access token.

Cheers,
-Tiru.

> Thanks
> Partha
> > 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,
> >
> > 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
> > 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
> > (dwing); [email-masked]
> > Cc: [email-masked]
> > Subject: [pcp] Comments on PCP Extension for Third Party Authorization
> > 1. Why can't we achieve this with http://tools.ietf.org/html/draft-
> > wasserman-pcp-authentication-02 and RFC6887.
> > should contact PCP server for opening ports for the data connections?
> > 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