idnits 2.17.1 draft-reddy-tram-turn-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 436 has weird spacing: '... long life...' -- The document date (June 19, 2014) is 3599 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) -- Looks like a reference, but probably isn't: '8' on line 435 ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-10 == Outdated reference: A later version (-05) exists of draft-ietf-tram-auth-problems-01 -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track R. Ravindranath 5 Expires: December 21, 2014 Cisco 6 J. Uberti 7 Google 8 June 19, 2014 10 TURN Extension for Third Party Authorization 11 draft-reddy-tram-turn-third-party-authz-03 13 Abstract 15 This document proposes the use of OAuth to obtain and validate 16 ephemeral tokens that can be used for TURN authentication. The usage 17 of ephemeral tokens ensure that access to a TURN server can be 18 controlled even if the tokens are compromised, as is the case in 19 WebRTC where TURN credentials must be specified in Javascript. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 21, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Obtaining a Token Using OAuth . . . . . . . . . . . . . . . . 5 59 4.1. Key Establishment . . . . . . . . . . . . . . . . . . . . 7 60 4.1.1. DSKPP . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1.2. HTTP interactions . . . . . . . . . . . . . . . . . . 8 62 4.1.3. Manual provisioning . . . . . . . . . . . . . . . . . 9 63 5. Forming a Request . . . . . . . . . . . . . . . . . . . . . . 10 64 6. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 10 65 6.1. THIRD-PARTY-AUTHORIZATION . . . . . . . . . . . . . . . . 10 66 6.2. ACCESS-TOKEN . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Receiving a request with ACCESS-TOKEN attribute . . . . . . . 12 68 8. Changes to TURN Client . . . . . . . . . . . . . . . . . . . 13 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 12.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 Traversal Using Relay NAT (TURN) TURN [RFC5766] is a protocol that is 80 often used to improve the connectivity of P2P applications. By 81 providing a cloud-based relay service, TURN ensures that a connection 82 can be established even when one or both sides is incapable of a 83 direct P2P connection. However, as a relay service, it imposes a 84 nontrivial cost on the service provider. Therefore, access to a TURN 85 service is almost always access-controlled. 87 TURN provides a mechanism to control access via "long-term" username/ 88 password credentials that are provided as part of the TURN protocol. 89 It is expected that these credentials will be kept secret; if the 90 credentials are discovered, the TURN server could be used by 91 unauthorized users or applications. However, in web applications, 92 ensuring this secrecy is typically impossible. To address this 93 problem and the ones described in [I-D.ietf-tram-auth-problems], this 94 document proposes the use of third party authorization using OAuth 95 for TURN. 97 To achieve third party authorization, a resource owner e.g. WebRTC 98 server, authorizes a TURN client to access resources on the TURN 99 server. 101 Using OAuth, a client obtains an ephemeral token from an 102 authorization server e.g. WebRTC server, and the token is presented 103 to the TURN server instead of the traditional mechanism of presenting 104 username/password credentials. The TURN server validates the 105 authenticity of the token and provides required services. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 o WebRTC Server: A web server that supports WebRTC 114 [I-D.ietf-rtcweb-overview]. 116 o Access Token: OAuth 2.0 access token. 118 o mac_key: The session key generated by the authorization server. 119 Note that the lifetime of the session key is equal to the lifetime 120 of the access token. 122 o kid: An ephemeral and unique key identifier. The kid also allows 123 the resource server to select the appropriate keying material for 124 decryption. 126 3. Solution Overview 128 This specification uses the token type 'Assertion' (aka self- 129 contained token) described in [RFC6819] where all the information 130 necessary to authenticate the validity of the token is contained 131 within the token itself. This approach has the benefit of avoiding a 132 protocol between the TURN server and the authorization server for 133 token validation, thus reducing latency. The exact mechanism used by 134 a client to obtain a token from the OAuth authorization server is 135 outside the scope of this document. For example, a client could make 136 an HTTP request to an authorization server to obtain a token that can 137 be used to avail TURN services. The TURN token is returned in JSON, 138 along with other OAuth Parameters like token type, mac_key, kid, 139 token lifetime etc. The client is oblivious to the content of the 140 token. The token is embedded within a TURN request sent to the TURN 141 server. Once the TURN server has determined the token is valid, TURN 142 services are offered for a determined period of time. 144 +-------------------+ +--------+ +---------+ 145 | ......... TURN | | TURN | | WebRTC | 146 | .WebRTC . Client | | | | | 147 | .Client . | | Server | | Server | 148 | ......... | | | | | 149 +-------------------+ +--------+ +---------+ 150 | | Allocate request | | 151 | |------------------------------------------>| | 152 | | | | 153 | | Allocate error response | | 154 | |<------------------------------------------| | 155 | | THIRD-PARTY-AUTHORIZATION | | 156 | | | | 157 | | | | 158 | | HTTP Request for token | | 159 |------------------------------------------------------------>| 160 | | HTTP Response with token parameters | | 161 |<------------------------------------------------------------| 162 |OAuth | | | 163 Attributes | | 164 |------>| | | 165 | | Allocate request ACCESS-TOKEN | | 166 | |------------------------------------------>| | 167 | | | | 168 | | Allocate success response | | 169 | |<------------------------------------------| | 170 | | TURN Messages | | 171 | | ////// integrity protected ////// | | 172 | | ////// integrity protected ////// | | 173 | | ////// integrity protected ////// | | 175 Figure 1: TURN Third Party Authorization 177 Note : An implementation may choose to contact the WebRTC server to 178 obtain a token even before it makes an allocate request, if it knows 179 the server details before hand. For example, once a client has 180 learnt that a TURN server supports Third Party authorization from a 181 WebRTC server, the client can obtain the token before making 182 subsequent allocate requests. 184 For example, the client learns the TURN server name 185 "turn1@example.com" from THIRD-PARTY-AUTHORIZATION attribute value 186 and makes the following HTTP request for the access token using 187 transport-layer security (with extra line breaks for display purposes 188 only): 190 POST /o/oauth2/token HTTP/1.1 191 Audience: turn1@example.com 192 Content-Type: application/x-www-form-urlencoded 193 timestamp=1361471629 194 grant_type=implicit 196 Figure 2: Request 198 If the client is authorized then the authorization server issues an 199 access token. An example of successful response: 201 HTTP/1.1 200 OK 202 Content-Type: application/json 203 Cache-Control: no-store 205 { 206 "access_token": 207 "U2FsdGVkX18qJK/kkWmRcnfHglrVTJSpS6yU32kmHmOrfGyI3m1gQj1jRPsr0uBb 208 HctuycAgsfRX7nJW2BdukGyKMXSiNGNnBzigkAofP6+Z3vkJ1Q5pWbfSRroOkWBn", 209 "token_type":"mac", 210 "expires_in":1800, 211 "kid":"22BIjxU93h/IgwEb", 212 "mac_key":"v51N62OM65kyMvfTI08O" 213 } 215 Figure 3: Response 217 Access token and other attributes issued by the authorization server 218 are explained in Section 6.2. 220 4. Obtaining a Token Using OAuth 222 A TURN client should know the authentication capability of the TURN 223 server before deciding to use third party authorization with it. A 224 TURN client initially makes a request without any authorization. If 225 the TURN server supports or mandates third party authorization, it 226 will return an error message indicating support for third party 227 authorization. The TURN server includes an ERROR-CODE attribute with 228 a value of 401 (Unauthorized), a nonce value in a NONCE attribute and 229 a SOFTWARE attribute that gives information about the TURN server's 230 software. The TURN servers also includes additional STUN attribute 231 THIRD-PARTY-AUTHORIZATION signaling the TURN client that the TURN 232 server supports third party authorization. 234 The following mapping of OAuth concepts to WebRTC is used : 236 +----------------------+----------------------------+ 237 | OAuth | WebRTC | 238 +======================+============================+ 239 | Client | WebRTC client | 240 +----------------------+----------------------------+ 241 | Resource owner | WebRTC server | 242 +----------------------+----------------------------+ 243 | Authorization server | Authorization server | 244 +----------------------+----------------------------+ 245 | Resource server | TURN Server | 246 +----------------------+----------------------------+ 248 Figure 4: OAuth terminology mapped to WebRTC terminology 250 Using the OAuth 2.0 authorization framework, a WebRTC client (third- 251 party application) obtains limited access to a TURN (resource server) 252 on behalf of the WebRTC server (resource owner or authorization 253 server). The WebRTC client requests access to resources controlled 254 by the resource owner (WebRTC server) and hosted by the resource 255 server (TURN server). The WebRTC client obtains access token, 256 lifetime, session key (in the mac_key parameter) and key id (kid). 257 The TURN client conveys the access token and other OAuth parameters 258 learnt from the authorization server to the resource server (TURN 259 server). The TURN server obtains the session key from the access 260 token. The TURN server validates the token, computes the message 261 integrity of the request and takes appropriate action i.e permits the 262 TURN client to create allocations. This is shown in an abstract way 263 in Figure 5. 265 +---------------+ 266 | +<******+ 267 +------------->| Authorization | * 268 | | Server | * 269 | +----------|(WebRTC Server)| * AS-RS, 270 | | | | * AUTH keys 271 (2) | | +---------------+ * (1) 272 Access | | (3) * 273 Token | | Access Token * 274 Request | | + * 275 | | Session Key * 276 | | * 277 | V V 278 +-------+---+ +-+----=-----+ 279 | | (4) | | 280 | | TURN Request + Access | | 281 | WebRTC | Token | TURN | 282 | Client |---------------------->| Server | 283 | (Alice) | Allocate Response | | 284 | |<----------------------| | 285 +-----------+ +------------+ 287 User : Alice 288 ****: Out-of-Band Long-Term Key Establishment 290 Figure 5: Interactions 292 OAuth in [RFC6749] defines four grant types. This specification uses 293 the OAuth grant type "Implicit" explained in section 1.3.2 of 294 [RFC6749] where the WebRTC client is issued an access token directly. 295 The scope of the access token explained in section 3.3 of [RFC6749] 296 MUST be TURN. 298 4.1. Key Establishment 300 The TURN and authorization servers MUST establish a symmetric key 301 (K), using an out of band mechanism. Symmetric key MUST be chosen to 302 ensure that the size of encrypted token is not large because usage of 303 asymmetric keys will result in large encrypted tokens which may not 304 fit into a single STUN message. The AS-RS, AUTH keys will be derived 305 from K. AS-RS key is used for encrypting the self-contained token 306 and message integrity of the encrypted token is calculated using the 307 AUTH key. The TURN and authorization servers MUST establish the 308 symmetric key over an authenticated secure channel. The 309 establishment of symmetric key is outside the scope of this 310 specification. For example, implementations could use one of the 311 following mechanisms in to establish a symmetric key. 313 4.1.1. DSKPP 315 The two servers could choose to use Dynamic Symmetric Key 316 Provisioning Protocol (DSKPP) [RFC6063] to establish a symmetric key 317 (K). The encryption and MAC algorithms will be negotiated using the 318 KeyProvClientHello, KeyProvServerHello messages. A unique key 319 identifier (referred to as KeyID) for the symmetric key is generated 320 by the DSKPP server (i.e. Authorization server) and signalled to the 321 DSKPP client (i.e TURN server) which is equivalent to the kid defined 322 in this specification. The AS-RS, AUTH keys would be derived from 323 the symmetric key using (HMAC)-based key derivation function (HKDF) 324 [RFC5869] and the default hash function is SHA-256. For example if 325 the input symmetric key (K) is 32 octets length, encryption algorithm 326 is AES_128_CBC and HMAC algorithm is HMAC-SHA-256-128 then the 327 secondary keys AS-RS, AUTH are generated from the input key K as 328 follows 330 1. HKDF-Extract(zero, K) -> PRK 332 2. HKDF-Expand(PRK, zero, 16) -> AS-RS key 334 3. HKDF-Expand(PRK, zero, 32) -> AUTH key 336 4.1.2. HTTP interactions 338 The two servers could choose to use REST API to establish a symmetric 339 key. To retrieve a new symmetric key, the TURN server makes an HTTP 340 GET request to the authorization server, specifying TURN as the 341 service to allocate the symmetric keys for, and specifying the name 342 of the TURN server. The response is returned with content-type 343 "application/json", and consists of a JSON object containing the 344 symmetric key. 346 Request 347 ------- 349 service - specifies the desired service (turn) 350 name - TURN server name be associated with the key 352 example: GET /?service=turn&name=turn1@example.com 354 Response 355 -------- 357 key - Long-term key (K) 358 ttl - the duration for which the key is valid, in seconds. 360 example: 361 { 362 "key" : 363 "ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1FXAghRMVTzkBGNaaN496523WIISKerLi", 364 "ttl" : 86400, 365 "kid" :"22BIjxU93h/IgwEb" 366 } 368 The AS-RS, AUTH keys are derived from K using HKDF as discussed in 369 Section 4.1.1. Authorization server must also signal a unique key 370 identifier (kid) to the TURN server which will be used to select the 371 appropriate keying material for decryption. The default encryption 372 algorithm to encrypt the self-contained token could be Advanced 373 Encryption Standard (AES) in Cipher Block Chaining (CBC) mode 374 (AES_128_CBC). The default HMAC algorithm to calculate the integrity 375 of the token could be HMAC-SHA-256-128. In this case AS-RS key 376 length must be 128-bit, AUTH key length must be 256-bit (section 2.6 377 of [RFC4868]). 379 4.1.3. Manual provisioning 381 TURN and authorization servers could be manually configured with a 382 symmetric key (K) and kid. The default encryption and HMAC 383 algorithms could be AES_256_CBC, HMAC-SHA-256-128. 385 Note : The mechanisms specified in Section 4.1.2 Section 4.1.3 are 386 easy to implement and deploy compared to DSKPP but lack encryption 387 and HMAC algorithm agility. 389 5. Forming a Request 391 When a TURN server responds that third party authorization is 392 required, a TURN client re-attempts the request, this time including 393 access token and kid values in ACCESS-TOKEN and USERNAME STUN 394 attributes. The TURN client includes a MESSAGE-INTEGRITY attribute 395 as the last attribute in the message over the contents of the TURN 396 message. The HMAC for the MESSAGE-INTEGRITY attribute is computed as 397 described in section 15.4 of [RFC5389] where the mac_key is used as 398 the input key for the HMAC computation. The TURN client and server 399 will use the mac_key to compute the message integrity and doesn't 400 have to perform MD5 hash on the credentials. 402 6. STUN Attributes 404 The following new STUN attributes are introduced by this 405 specification to accomplish third party authorization. 407 6.1. THIRD-PARTY-AUTHORIZATION 409 This attribute is used by the TURN server to inform the client that 410 it supports third party authorization. This attribute value contains 411 the TURN server name. The TURN server may have tie-up with multiple 412 authorization servers and vice versa, so the client MUST provide the 413 TURN server name to the authorization server so that it can select 414 the appropriate keying material to generate the self-contained token. 415 The THIRD-PARTY-AUTHORIZATION attribute is a comprehension-optional 416 attribute (see Section 15 from [RFC5389]). 418 6.2. ACCESS-TOKEN 420 The access token is issued by the authorization server. OAuth does 421 not impose any limitation on the length of the access token but if 422 path MTU is unknown then STUN messages over IPv4 would need to be 423 less than 548 bytes (Section 7.1 of [RFC5389]), access token length 424 needs to be restricted to fit within the maximum STUN message size. 425 Note that the self-contained token is opaque to the client and it 426 MUST NOT examine the ticket. The ACCESS-TOKEN attribute is a 427 comprehension-optional attribute (see Section 15 from [RFC5389]). 429 The token is structured as follows: 431 struct { 432 opaque { 433 ushort key_length; 434 opaque mac_key[key_length]; 435 opaque timestamp[8]; 436 long lifetime; 437 } encrypted_block; 438 opaque mac[mac_length]; 439 } token; 441 Figure 6: Self-contained token format 443 The fields are described below: 445 key_length: Length of the session key. Key length of 160-bits MUST 446 be supported (i.e only 160-bit key is used by HMAC-SHA-1 for 447 message integrity of STUN message). The key length facilitates 448 the hash agility plan discussed in section 16.3 of [RFC5389]. 450 mac_key: The session key generated by the authorization server. 452 Timestamp: 64-bit unsigned integer field containing a timestamp. 453 The value indicates the time since January 1, 1970, 00:00 UTC, by 454 using a fixed point format. In this format, the integer number of 455 seconds is contained in the first 48 bits of the field, and the 456 remaining 16 bits indicate the number of 1/64K fractions of a 457 second (Native format - Unix). 459 Lifetime: The lifetime of the access token, in seconds. For 460 example, the value 3600 indicates one hour. The Lifetime value 461 SHOULD be equal to the "expires_in" parameter defined in section 462 4.2.2 of [RFC6749]. 464 mac: The Hashed Message Authentication Code (HMAC) is calculated 465 with AUTH key over the encrypted portion of the token and the TURN 466 server name (N) conveyed in the THIRD-PARTY-AUTHORIZATION response 467 . Encryption is applied before authentication on the sender side 468 and conversely on the receiver side. The length of the mac field 469 is known to the TURN and authorization server based on the 470 negotiated MAC algorithm. 472 For example the encryption process can be illustrated as follows. 473 Here C, N denote the ciphertext and TURN server name. 475 o C = AES_128_CBC(AS-RS, encrypted_block) 477 o mac = HMAC-SHA-256-128(AUTH, C | | N) 478 The token MUST be encoded as defined in Section 4 of [RFC4648] and 479 then encrypted using the symmetric long-term key established between 480 the resource server and the authorization server, as shown in 481 Figure 5 as AS-RS key. HMAC is computed using the encrypted portion 482 of the token and TURN server name to ensure that the client does not 483 use the same token to gain illegal access to other TURN servers 484 provided by the same administrative domain. This attack is possible 485 when multiple TURN servers in a single administrative domain share 486 the same symmetric key with the authorization server. Since the 487 access token is valid for a specific period of time the resource 488 server MUST cache it so that it need not to be provided in every 489 request within an existing allocation. The access token can be re- 490 used for multiple Allocate requests to the same TURN server. 492 The TURN client MUST include the ACCESS-TOKEN attribute only in 493 Allocate and Refresh requests. 495 7. Receiving a request with ACCESS-TOKEN attribute 497 The TURN server, on receiving a request with ACCESS-TOKEN attribute, 498 performs checks listed in section 10.2.2 of [RFC5389] in addition to 499 the following steps to verify that the access token is valid: 501 o TURN server selects the keying material based on kid signalled in 502 the USERNAME attribute. 504 o It performs the verification of the token message integrity by 505 calculating HMAC over the encrypted portion in the self-contained 506 token and TURN server name using AUTH key and if the resulting 507 value does not match the mac field in the self-contained token 508 then it rejects the request with an error response 401 509 (Unauthorized). 511 o TURN server obtains the mac_key by retrieving the content of the 512 access token (which requires decryption of the self-contained 513 token using the AS-RS key). 515 o The TURN server verifies that no replay took place by performing 516 the following check: 518 * The access token is accepted if the timestamp field (TS) in the 519 self-contained token is recent enough to the reception time of 520 the TURN request (RDnew) using the following formula: Lifetime 521 + Delta > abs(RDnew - TS). The RECOMMENDED value for the 522 allowed Delta is 5 seconds. If the timestamp is NOT within the 523 boundaries then the TURN server discards the request with error 524 response 401 (Unauthorized). 526 o The TURN server uses the mac_key to compute the message integrity 527 over the request and if the resulting value does not match the 528 contents of the MESSAGE-INTEGRITY attribute then it rejects the 529 request with an error response 401 (Unauthorized). 531 o If all the checks pass, the TURN server continues to process the 532 request. Any response generated by the server MUST include the 533 MESSAGE-INTEGRITY attribute, computed using the mac_key. 535 The lifetime provided by the TURN server in the Allocate and Refresh 536 responses MUST be less than or equal to the lifetime of the token. 538 8. Changes to TURN Client 540 o A TURN response is discarded by the client if the value computed 541 for message integrity using mac_key does not match the contents of 542 the MESSAGE-INTEGRITY attribute. 544 o If the access token expires then the client MUST obtain a new 545 token from the authorization server and use it for new 546 allocations. The client MUST also use the new token to refresh 547 existing allocations. This way client has to maintain only one 548 token per TURN server. 550 9. Security Considerations 552 When OAuth is used the interaction between the client and the 553 authorization server requires Transport Layer Security (TLS) with a 554 ciphersuite offering confidentiality protection. The session key 555 MUST NOT be transmitted in clear since this would completely destroy 556 the security benefits of the proposed scheme. If an attacker tries 557 to replay message with ACCESS-TOKEN attribute then the server can 558 detect that the transaction ID as used for an old request and thus 559 prevent the replay attack. 561 Security considerations discussed in [I-D.ietf-oauth-v2-http-mac] and 562 [RFC5766] are to be taken into account. 564 10. IANA Considerations 566 IANA is requested to add the following attributes to the STUN 567 attribute registry [iana-stun], 569 o THIRD-PARTY-AUTHORIZATION 571 o ACCESS-TOKEN 573 11. Acknowledgements 575 Authors would like to thank Dan Wing, Pal Martinsen, Oleg Moskalenko 576 and Charles Eckel for comments and review. The authors would like to 577 give special thanks to Brandon Williams for his help. 579 12. References 581 12.1. Normative References 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 587 Encodings", RFC 4648, October 2006. 589 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 590 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 592 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 593 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 594 October 2008. 596 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 597 6749, October 2012. 599 [iana-stun] 600 IANA, , "IANA: STUN Attributes", April 2011, 601 . 604 12.2. Informative References 606 [I-D.ietf-oauth-v2-http-mac] 607 Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth 608 2.0 Message Authentication Code (MAC) Tokens", draft-ietf- 609 oauth-v2-http-mac-05 (work in progress), January 2014. 611 [I-D.ietf-rtcweb-overview] 612 Alvestrand, H., "Overview: Real Time Protocols for 613 Browser-based Applications", draft-ietf-rtcweb-overview-10 614 (work in progress), June 2014. 616 [I-D.ietf-tram-auth-problems] 617 Reddy, T., R, R., Perumal, M., and A. Yegin, "Problems 618 with STUN long-term Authentication for TURN", draft-ietf- 619 tram-auth-problems-01 (work in progress), May 2014. 621 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 622 Relays around NAT (TURN): Relay Extensions to Session 623 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 625 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 626 Key Derivation Function (HKDF)", RFC 5869, May 2010. 628 [RFC6063] Doherty, A., Pei, M., Machani, S., and M. Nystrom, 629 "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", RFC 630 6063, December 2010. 632 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 633 Threat Model and Security Considerations", RFC 6819, 634 January 2013. 636 Authors' Addresses 638 Tirumaleswar Reddy 639 Cisco Systems, Inc. 640 Cessna Business Park, Varthur Hobli 641 Sarjapur Marathalli Outer Ring Road 642 Bangalore, Karnataka 560103 643 India 645 Email: tireddy@cisco.com 647 Prashanth Patil 648 Cisco Systems, Inc. 649 Bangalore 650 India 652 Email: praspati@cisco.com 654 Ram Mohan Ravindranath 655 Cisco Systems, Inc. 656 Cessna Business Park, 657 Kadabeesanahalli Village, Varthur Hobli, 658 Sarjapur-Marathahalli Outer Ring Road 659 Bangalore, Karnataka 560103 660 India 662 Email: rmohanr@cisco.com 663 Justin Uberti 664 Google 665 747 6th Ave S 666 Kirkland, WA 667 98033 668 USA 670 Email: justin@uberti.name