idnits 2.17.1 draft-wing-pcp-third-party-authz-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 2, 2014) is 3649 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5389' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC6407' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC6342' is defined on line 646, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-03 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-05 ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-09 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP D. Wing 3 Internet-Draft T. Reddy 4 Intended status: Standards Track P. Patil 5 Expires: October 4, 2014 R. Penno 6 Cisco 7 April 2, 2014 9 PCP Extension for Third Party Authorization 10 draft-wing-pcp-third-party-authz-03 12 Abstract 14 It is often desirable for an application server to permit a flow 15 across a firewall, as happens today when a firewall includes an 16 Application Layer Gateway (ALG) function. However, an ALG has 17 several weaknesses. 19 This document describes a cryptographic technique for an application 20 server to permit a flow across a firewall. This technique uses OAuth 21 and a new PCP option. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 4, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 59 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Obtaining a Token Using OAuth . . . . . . . . . . . . . . . . 6 62 5.1. ACCESS_TOKEN Option . . . . . . . . . . . . . . . . . . . 7 63 5.2. Generating the ACCESS_TOKEN option . . . . . . . . . . . 9 64 5.3. PCP server processing ACCESS_TOKEN option . . . . . . . . 10 65 5.4. Processing the PCP response . . . . . . . . . . . . . . . 11 66 6. PCP Server and Proxy behavior . . . . . . . . . . . . . . . . 11 67 7. Usage with PCP Authentication mechanism . . . . . . . . . . . 12 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 73 11.2. Informative References . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 It is desirable for a third party to permit flows across a firewall. 79 A typical use-case is a SIP proxy (which is aware of legitimate 80 calls) which is not co-located with a firewall. Today, this 81 functionality is provided by a firewall implementing a SIP-aware 82 Application Layer Gateway function, which examines the SIP signaling 83 to that SIP proxy and opens the appropriate pinholes for the RTP 84 media. This has disadvantages, as described in detail in section 85 Section 3. 87 This document addresses requirement "Third Party Authorization" 88 explained in section 4 of [I-D.reddy-pcp-auth-req]. 90 This document proposes that a PCP [RFC6887] client communicate with 91 an OAuth Authorization Server to obtain a cryptographic token for its 92 media flow. That token is included in the PCP request and validated 93 by the PCP server. 95 Note: There is no relationship with the THIRD_PARTY option defined in 96 [RFC6887], which serves a different purpose. THIRD_PARTY Option for 97 MAP and PEER Opcodes described in [RFC6887] is only applicable when 98 all entities i.e the PCP client, PCP server and Application Server, 99 are deployed within the same administrative domain. Since PCP server 100 does not listen on a public interface, an Application Server outside 101 the site will not be able to use THIRD_PARTY option to request 102 services on behalf of the client. 104 2. Notational Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 WebRTC Server: A web server that supports WebRTC 111 [I-D.ietf-rtcweb-overview]. 113 3. Problem Statement 115 To protect networks using real-time communications, firewalls or 116 session border controllers [RFC5853] are typically deployed. 117 Firewalls usually implement Application Layer Gateway functionality, 118 which intercepts and analyzes session signaling traffic such as 119 Session Initiation Protocol (SIP) [RFC3261] messages and creates a 120 dynamic mapping to permit the corresponding media traffic. In 121 particular, a firewall extracts media transport addresses, transport 122 protocol and ports from session description and creates a dynamic 123 mapping for media to flow through. This model will not work in the 124 following cases: 126 1. Session signaling is end-to-end encrypted (say, using TLS). 128 2. Firewall does not understand the session signaling protocol, or 129 extensions to the protocol, used by the endpoints. 131 3. Session signaling and media traverse different firewalls (e.g., 132 signaling exits a network via one firewall whereas media exits a 133 network via a different firewall) 135 When an enterprise deploys WebRTC, the above problems are relevant 136 because: 138 1. Session signaling between WebRTC application running in a browser 139 and a web server will use TLS. 141 2. WebRTC does not enforce a particular session signaling protocol; 142 therefore, a firewall is unlikely to understand the signaling 143 protocol. 145 3. Session signaling and peer-to-peer media may traverse different 146 firewalls. 148 As a result firewalls block media traffic. 150 A mitigation to the problems above is for an enterprise to deploy a 151 TURN server in the DMZ and have WebRTC clients use the TURN server. 152 The use-case explained in Section 4.2.5.1 of 153 [I-D.ietf-rtcweb-use-cases-and-requirements] refers to deploying a 154 TURN [RFC5766] server to audit all media sessions from inside the 155 company premises to any external peer. 157 However, using TURN for all such communication causes some problems 158 for an enterprise network administrator : 160 o Enterprise firewalls would typically have granular policies to 161 permit calls initiated using selected WebRTC servers (Dr. Good) it 162 trusts and block the rest (Dr. Evil). 164 o A TURN server just provides a 5-tuple (source IP address, 165 destination IP address, protocol number, source port number, and 166 destination port number) for auditing and no other details of the 167 WebRTC or SIP server being used to establish the call. 169 o A TURN server could increase media latency as explained in section 170 4.1.2.2 of [RFC5245]. 172 o A TURN server could either be located in the DMZ of the enterprise 173 network or located in the public Internet. If the TURN server is 174 located in the public Internet it comes at a high cost to the 175 provider of the TURN server, since the server typically needs a 176 high-bandwidth connection to the Internet as explained in the 177 Introduction of [RFC5766]. As a consequence, it is best to use a 178 TURN server only when a direct communication path cannot be found. 179 When the client and a peer use ICE to determine communication 180 path, ICE will use hole punching techniques to search for a direct 181 path first and only use a TURN server when a direct path cannot be 182 found. 184 o Other limitations of TURN are explained in section 2.6 of 185 [RFC5766]. For example the value of Diffserv field may not be 186 preserved, Explicit Congestion Notification (ECN) field may be 187 reset etc. 189 4. Solution Overview 191 In the below topology, the main functional elements involved are : 193 ========================= 194 | WebRTC Server | 195 ========================= 196 | 3rd Party Network 197 | 198 | 199 ================== 200 | WAN |-----+-+----+---+----+-+--- 201 ================== | 202 | | 203 | | 204 | | 205 +-------+-------+ | 206 | Firewall - | | 207 | PCP Server | | 208 +-------+-------+ | 209 | | 210 | | 211 Branch office | | Mobile Network 212 -+-+-----+-----------+-+-----+-------- ----+-+-------+------ 213 | | 214 +-+----------+ +--------+ 215 | Alice - | | Bob | 216 | PCP Client | | | 217 +------------+ +--------+ 219 Users : Alice, Bob 220 WebRTC Server : OAuth 2.0 Authorization server 222 Figure 1: WebRTC server in a different administrative domain 224 In the topology, a WebRTC Server is deployed in a third party network 225 trusted by the Enterprise. For the two endpoints to successfully 226 establish media sessions, a firewall needs to permit ICE [RFC5245] 227 connectivity checks and subsequent media traffic. 229 In such a scenario this specification proposes that a PCP client 230 follows the steps described below: 232 1. The PCP client makes a PCP request without any authorization. If 233 the PCP server returns an AUTHORIZATION_REQUIRED error message, 234 the PCP client concludes that the PCP server is mandating the use 235 of third party authorization. 237 2. The PCP client then obtains a cryptographic token from an OAuth 238 2.0 Authorization server. 240 3. The PCP client sends a PCP request including the cryptographic 241 token in the TOKEN_ACCESS option, defined below. Alternatively, 242 the PCP client could first obtain a cryptographic token from the 243 OAuth 2.0 Authorization server and send the PCP request with the 244 TOKEN_ACCESS option by default. 246 4. The PCP server uses the TOKEN_ACCESS option to perform third 247 party authorization. 249 The technique proposed in the specification can be used by any other 250 Application Function trusted by the network to permit time-bound, 251 encrypted, peer-to-peer traffic. 253 5. Obtaining a Token Using OAuth 255 This section explains OAuth 2.0 authorization framework [RFC6749] to 256 solve the "Third Party Authorization" requirement explained in 257 section 4 of [I-D.reddy-pcp-auth-req]. 259 The following mapping of OAuth concepts to PCP is used : 261 +----------------------+----------------------------+ 262 | OAuth | PCP | 263 +======================+============================+ 264 | Client | PCP Client | 265 +----------------------+----------------------------+ 266 | Resource owner | Authorization Server. For | 267 | | example the WebRTC server | 268 +----------------------+----------------------------+ 269 | Authorization server | Authorization server. | 270 +----------------------+----------------------------+ 271 | Resource server | PCP Server | 272 +----------------------+----------------------------+ 274 Figure 2: OAuth terminology mapped to PCP terminology 276 Using the OAuth 2.0 authorization framework, a PCP client (third- 277 party application) obtains limited access to a PCP server (resource 278 server) on behalf of the WebRTC server (resource owner or 279 authorization server). The PCP client requests access to resources 280 controlled by the resource owner (WebRTC server) and hosted by the 281 resource server (PCP server). The PCP client obtains an access 282 token, lifetime, and other access attributes like the PCP options and 283 opcodes that the PCP client is permitted to use from the 284 authorization server. The PCP client conveys the token in the PCP 285 ACESS_TOKEN option to access the protected resources hosted by the 286 resource server (PCP server). The PCP server validates the token and 287 takes appropriate action e.g., allows the PCP request to create 288 mappings on the PCP server. 290 +---------------+ 291 +-------------->| +-------+ 292 | | Authorization | | 293 | +--------| Server | | 294 | | |(WebRTC Server)| | Authorization 295 | | | |<--+ | (e.g Permit MAP/PEER) 296 (1) | | +---------------+ | | (5) 297 Access | | Access | | 298 Token | | Token Get Token | | 299 Request| | (2) Resource | | 300 | | (4) | | 301 | | | | 302 | V | V 303 +-------+---+ +-+----=-----+ 304 | | (3) | | 305 | | PCP Request + Access | | 306 | PCP | Token | PCP | 307 | Client |---------------------->| Server | 308 | (Alice) | PCP Response (6) | (Firewall) | 309 | |<----------------------| | 310 +-----------+ +------------+ 312 User : Alice 314 Figure 3: Interactions 316 OAuth in [RFC6749] defines four grant types. This specification uses 317 the OAuth grant type "Implicit" explained in section 1.3.2 of 318 [RFC6749] where the PCP client is issued an access token directly. 319 The scope of the access token explained in section 3.3 of [RFC6749] 320 MUST be PCP. 322 5.1. ACCESS_TOKEN Option 324 This specification defines a new PCP ACCESS_TOKEN Option that is 325 described inFigure 4. 327 0 1 2 3 328 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 |Option Code=TBD| Reserved | Option Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Domain Name Length | Reserved1 | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | 335 | Domain Name | 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Timestamp | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Lifetime | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | key id | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | access token length | Reserved3 | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | access token | 347 | | 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 4: PCP ACCESS_TOKEN Option 353 The fields are described below: 355 Option Length: 16 bits. Indicates the length of the enclosed data, 356 in octets. Variable, but MUST NOT be 0. 358 Domain Name Length: Length of the 'Domain Name' field in octets. 360 Reserved1: set to 0 by sender and ignored by the receiver. 362 Server Domain Name: The domain name of the Authorized Server that 363 generated the access token. 365 Timestamp: 64-bit unsigned integer field containing a timestamp. 366 The value indicates the time since January 1, 1970, 00:00 UTC, by 367 using a fixed point format. In this format, the integer number of 368 seconds is contained in the first 48 bits of the field, and the 369 remaining 16 bits indicate the number of 1/64K fractions of a 370 second (Native format - Unix). 372 Lifetime: The lifetime of the access token since the response was 373 generated, in seconds. For example, the value 3600 indicates one 374 hour. The Lifetime value SHOULD be equal to the "expires_in" 375 parameter defined in section 4.2.2 of [RFC6749]. 377 key id: An ephemeral and unique key identifier generated by the 378 authorization server. The authorization server MUST NOT generate 379 the same key identifier twice within the lifetime of the access 380 token. 382 access token length: Length of the access token field in octets. 383 OAuth does not impose any limitation on the length of the access 384 token but since PCP messages cannot exceed 1100 octets (Section 7 385 of [RFC6887]), access token length needs to be restricted to fit 386 within the maximum PCP message size. The access token is defined 387 in section 1.4 of [RFC6749]. TBD : what is the recommended/ 388 maximum token length for PCP. We need a discussion of this 389 maximum length and analysis of what that means 391 Reserved3: set to 0 by sender and ignored by the receiver. 393 access token: The access token issued by the authorization server. 395 Option Name: ACCESS_TOKEN 397 Number: TBA in the mandatory-to-process range (IANA) 399 Purpose: This option conveys the token granted by the authorization 400 server for third party authorization. 402 Valid for Opcodes: MAP, PEER 404 May appear in : request. 406 Maximum occurrences : 1 408 5.2. Generating the ACCESS_TOKEN option 410 The mechanism used by an OAuth client to obtain a token from the 411 OAuth authorization server is outside the scope of this document. 412 The OAuth client could obtain the token via in-band signaling or an 413 exclusive out-of-band protocol. This specification uses the token 414 type Handle described in [RFC6819]. A handle token is a reference to 415 some internal data structure within the OAuth authorization server; 416 the internal data structure contains the attributes of the token such 417 as allowed PCP Opcode or PCP Option, etc. The PCP client, after 418 receiving the access token from the OAuth authorization server, 419 generates the ACCESS_TOKEN option which is included in the PCP 420 request to the PCP server. 422 5.3. PCP server processing ACCESS_TOKEN option 424 A PCP server performs processing in the order described below. 426 When a PCP server receives a PCP request with an ACCESS_TOKEN option, 427 it will verify that the access token is valid. To address replay 428 attacks, the PCP server MUST perform the following check : 430 When a PCP request with an ACCESS_TOKEN Option is received, the 431 received timestamp (TSnew in the Timestamp field) is checked and the 432 cryptographic token is accepted if the timestamp is recent enough to 433 the reception time of the PCP request, RDnew : 435 Lifetime + Delta > abs(RDnew - TSnew) 437 The RECOMMENDED value for the allowed Delta is 5 seconds. If the 438 timestamp is NOT within the boundaries then discard the PCP request 439 with AUTHORIZATION-FAILED error response defined in 440 [I-D.ietf-pcp-authentication]. 442 After the validation described above, the PCP server communicates 443 with the authorization server in order to validate the token and 444 obtain token-bound data. The mechanism for communication is outside 445 the scope of this document. The PCP server makes a request to the 446 authorization server to validate the token but produces no other data 447 with the request. If the token is successfully validated, the 448 authorization server just returns the token bound authorization data 449 in the response. The PCP server then matches this authorization data 450 with what is requested in the PCP request sent by the PCP client. If 451 the authorization sets match, the PCP server honors the PCP request 452 made by the PCP client. 454 If the token is invalid or the request exceeds what is authorized by 455 the token then the PCP server generates an AUTHORIZATION-FAILED error 456 response. An example might be that an OAuth authorization server 457 permits creating 5 mappings, and the PCP request made by the client 458 is trying to create a 6th mapping. 460 Handle token type was selected for the following reasons : 462 1. The Authorization Server can inform the PCP server to revoke the 463 access token after the call is terminated. This mechanism 464 ensures that even if the PCP client does not close the dynamic 465 mapping created, the PCP server based on the revocation 466 notification from the Authorization Server can close the dynamic 467 mapping. 469 2. A PCP-controlled Firewall with restrictive policies may also want 470 to validate with the Authorization Server if the selected 471 candidate pairs in the final offer/answer match the 5-tuple {dest 472 addr, source addr, protocol, dest port, source port} sessions 473 traversing the Firewall. This validation ensures that the PCP 474 client is using the token only to send and receive the media 475 streams finalized in the call to the remote peer. Thus the PCP 476 server can make sure that the token cannot be used for anything 477 else. 479 3. If PCP authentication [I-D.ietf-pcp-authentication] is used then 480 the PCP server may also validate with the authorization server if 481 the access token is issued and used by the same user or not. 483 Another approach, not discussed in this document, is a self-contained 484 token where all the information necessary to authenticate the 485 validity of the token is contained within the token itself. This 486 approach has the benefit of avoiding a protocol between the PCP 487 server and the OAuth authentication server for token validation, thus 488 reducing latency. However, this approach has the drawback of needing 489 a large PCP packet to accommodate the token. Because PCP messages 490 are limited to 1100 octets, using the handle approach is more 491 flexible and the trade-off for additional latency is reasonable. The 492 other disadvantages of self-contained tokens, such as difficulties 493 with revocation etc., are discussed in[RFC6819]. 495 5.4. Processing the PCP response 497 Upon receiving a PCP response, the PCP client performs the normal 498 processing described in Section 8.3 of [RFC6887]. If the PCP 499 response was SUCCESS (0), the PCP server has determined that the 500 token is valid. If the PCP response was AUTHORIZATION-FAILED, it 501 indicates that the token could be invalid, expired or the PCP request 502 exceeded what is authorized by the token. 504 6. PCP Server and Proxy behavior 506 The ACCESS_TOKEN option is mandatory-to-process (its most significant 507 bit is clear). Thus, per existing behavior described in [RFC6887], a 508 PCP server receiving this option MUST return the error 509 MALFORMED_OPTION if the option contents are malformed, or 510 UNSUPP_OPTION if the option is unrecognized, unimplemented, or 511 disabled, or if the client is not authorized to use the option. 513 A PCP Proxy MUST follow the rules mentioned in section of 3.4 of 514 [I-D.ietf-pcp-proxy] when processing the ACCESS_TOKEN option. 516 7. Usage with PCP Authentication mechanism 518 The following steps MUST be followed when PCP third party 519 authorization is used with PCP authentication mechanism. 521 o PCP client MUST send the access token after successful EAP 522 authentication. This provides integrity protection for 523 ACCESS_TOKEN option. 525 o If PCP Auth session lifetime expires before the authorization 526 token expires and the PCP client, PCP server fail to trigger re- 527 authentication then dynamic mappings created because of third 528 party authorization MUST be deleted. 530 8. Security Considerations 532 Security considerations discussed in [RFC6887] and PCP authentication 533 [I-D.ietf-pcp-authentication] are to be taken into account. If left 534 unprotected the Authorization server could present a means for an 535 attacker to poll a series of possible token values, fishing for a 536 valid token. Therefore, the Authorization Server SHOULD issue 537 special credentials to PCP server to access it and the communication 538 between PCP server and Authorization server MUST be protected using 539 TLS. 541 A PCP server will delete explicit dynamic mappings after the lifetime 542 of the cryptographic token expires. The PCP client must obtain a new 543 cryptographic token from the authorization server before the current 544 token becomes invalid or expires. The PCP client must propagate the 545 new cryptographic token to the PCP server to refresh lifetime of 546 mappings before the current token becomes invalid or expires. The 547 PCP server in addition to timestamp checking can also maintain a 548 cache of used key id as an effective countermeasure against replay 549 attacks. 551 Discussion: If the additional latency needs to be avoided and it is 552 permissible to create a PCP mapping briefly for PCP clients, an 553 implementation could create PCP mappings while the token is being 554 validated. The PCP server could create a mapping immediately, send a 555 PCP response and in parallel start verification of the token. If the 556 verification request times out or returns a failure response, the PCP 557 mapping can be destroyed and a PCP mapping update is sent to the PCP 558 client. The PCP server while waiting for the validation response to 559 arrive from Authorization server can either drop or buffer the 560 traffic matching the mapping created. 562 9. IANA Considerations 564 We request IANA register the PCP option ACCESS_TOKEN and the result 565 code AUTHORIZATION_REQUIRED in [pcp-registry]. 567 10. Acknowledgements 569 Authors would like to thank Dave Thaler, Charles Eckel, Paul Jones, 570 Dacheng Zhang, Anca Zamfir, Parthasarathi R and Suresh kumar for 571 their comments and review. 573 11. References 575 11.1. Normative References 577 [I-D.ietf-pcp-authentication] 578 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 579 Protocol (PCP) Authentication Mechanism", draft-ietf-pcp- 580 authentication-03 (work in progress), February 2014. 582 [I-D.ietf-pcp-proxy] 583 Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. 584 Cheshire, "Port Control Protocol (PCP) Proxy Function", 585 draft-ietf-pcp-proxy-05 (work in progress), February 2014. 587 [I-D.reddy-pcp-auth-req] 588 Reddy, T., Patil, P., Wing, D., and R. Penno, "PCP 589 Authentication Requirements", draft-reddy-pcp-auth-req-04 590 (work in progress), July 2013. 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, March 1997. 595 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 596 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 597 October 2008. 599 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 600 of Interpretation", RFC 6407, October 2011. 602 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 603 6749, October 2012. 605 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 606 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 607 2013. 609 [pcp-registry] 610 IANA, , "Port Control Protocol (PCP) Parameters", May 611 2013, . 614 11.2. Informative References 616 [I-D.ietf-rtcweb-overview] 617 Alvestrand, H., "Overview: Real Time Protocols for Brower- 618 based Applications", draft-ietf-rtcweb-overview-09 (work 619 in progress), February 2014. 621 [I-D.ietf-rtcweb-use-cases-and-requirements] 622 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 623 Time Communication Use-cases and Requirements", draft- 624 ietf-rtcweb-use-cases-and-requirements-14 (work in 625 progress), February 2014. 627 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 628 A., Peterson, J., Sparks, R., Handley, M., and E. 629 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 630 June 2002. 632 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 633 (ICE): A Protocol for Network Address Translator (NAT) 634 Traversal for Offer/Answer Protocols", RFC 5245, April 635 2010. 637 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 638 Relays around NAT (TURN): Relay Extensions to Session 639 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 641 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 642 A., and M. Bhatia, "Requirements from Session Initiation 643 Protocol (SIP) Session Border Control (SBC) Deployments", 644 RFC 5853, April 2010. 646 [RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 647 Deployment", RFC 6342, August 2011. 649 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 650 Threat Model and Security Considerations", RFC 6819, 651 January 2013. 653 Authors' Addresses 655 Dan Wing 656 Cisco Systems, Inc. 657 170 West Tasman Drive 658 San Jose, California 95134 659 USA 661 Email: dwing@cisco.com 663 Tirumaleswar Reddy 664 Cisco Systems, Inc. 665 Cessna Business Park, Varthur Hobli 666 Sarjapur Marathalli Outer Ring Road 667 Bangalore, Karnataka 560103 668 India 670 Email: tireddy@cisco.com 672 Prashanth Patil 673 Cisco Systems, Inc. 674 Bangalore 675 India 677 Email: praspati@cisco.com 679 Reinaldo Penno 680 Cisco Systems, Inc. 681 170 West Tasman Drive 682 San Jose 95134 683 USA 685 Email: repenno@cisco.com