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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Anca,

Thanks for the review. Please see inline [TR]

From: Anca Zamfir (ancaz) 
Sent: Wednesday, January 29, 2014 4:56 PM
To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati)
Cc: [e-mail]
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 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?)

[TR]  Yes, updated.

. I don't understand the paragraph after bullet 4 and how is relevant to this section/ draft? What do you mean by "This technique"?

[TR] Replaced "This technique" with " The technique proposed in the specification". 
The paragraph explains how this technique can be used with PCP-aware NAT to permit MAP request after the client has got the token. 

Section 5:

. Figure 3: Show a bidirectional Request/ Response on (1). Show a (5) arrow with PCP Response so the loop is closed.

[TR]  Fixed.

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

[TR]  Yes,  The authorization server in this specific example has to be the WebRTC server because only it will be aware of call termination details to revoke the token.

. Create section 5.1 for the option detail and say something like "This specification defines the new PCP ACCESS_TOKEN Option."

[TR] ok.

. 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

[TR]  Yes and its variable length.

. "Reserved1": set to 0 by sender and ignored by the receiver?

[TR] Added
 
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.

[TR] The PCP servers uses the lifetime field to do local validation before interacting with the Authorization Server for further checks. Yes, this is the expires_in value that the PCP Client got from the Authorization server.  Performing local validation is just a minor benefit and anyways the PCP Server will ensure that the token has not expired by interacting with the authorization server.

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

[TR] Sure. 
Using the formula "Lifetime + Delta > abs(RDnew - TSnew)" defined in section 7 of the draft, PCP server can find out if the Timestamp field in the ACCESS_TOKEN option is too old when compared to the receipt of the PCP request.


. 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 

[TR] If the token is valid then the PCP server generates a success PCP response (it's the same as in RFC 6887, no changes)

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

[TR] It's covered in Section 7 "Security Considerations"

<snip>
A PCP server will delete explicit dynamic mappings after the lifetime of the cryptographic token expires. The PCP client must obtain a new cryptographic token from the authorization server before the current token becomes invalid or expires. The PCP client must propagate the new cryptographic token to the PCP server to refresh lifetime of mappings before the current token becomes invalid or expires
</snip>

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

[TR]  PCP Proxy will replay the ACCESS_TOKEN option because it's a mandatory-to-process option. For more information on the PCP proxy behavior w.r.t mandatory-to-process option please refer to section 7 in http://tools.ietf.org/html/draft-ietf-pcp-proxy-04#section-7 

Cheers,
-Tiru.

thanks,
-anca