idnits 2.17.1 draft-ietf-oauth-spop-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines 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 -- The document date (December 07, 2014) is 3427 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) == Missing Reference: 'A-Z' is mentioned on line 199, but not defined == Missing Reference: '0-9' is mentioned on line 199, but not defined == Missing Reference: 'RFC5226' is mentioned on line 354, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group N. Sakimura, Ed. 3 Internet-Draft Nomura Research Institute 4 Intended status: Standards Track J. Bradley 5 Expires: June 08, 2015 Ping Identity 6 N. Agarwal 7 Google 8 December 07, 2014 10 Symmetric Proof of Possession for the OAuth Authorization Code Grant 11 draft-ietf-oauth-spop-05 13 Abstract 15 The OAuth 2.0 public client utilizing Authorization Code Grant (RFC 16 6749 - 4.1) is susceptible to the code interception attack. This 17 specification describes a mechanism that acts as a control against 18 this threat. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 08, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Client creates a code verifier . . . . . . . . . . . . . . 4 59 4.2. Client creates the code challenge . . . . . . . . . . . . 5 60 4.3. Client sends the code challenge with the authorization 61 request . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.4. Server returns the code . . . . . . . . . . . . . . . . . 5 63 4.4.1. Error Response . . . . . . . . . . . . . . . . . . . . 6 64 4.5. Client sends the code and the secret to the token endpoint 6 65 4.6. Server verifies code_verifier before returning the tokens 6 66 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. OAuth Parameters Registry . . . . . . . . . . . . . . . . 7 69 6.2. SPOP Code Challenge Method Registry . . . . . . . . . . . 7 70 6.2.1. Registration Template . . . . . . . . . . . . . . . . 8 71 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 8 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7.1. Entropy of the code verifier . . . . . . . . . . . . . . . 9 74 7.2. Protection against eavesdroppers . . . . . . . . . . . . . 9 75 7.3. Checking the Server support . . . . . . . . . . . . . . . 9 76 7.4. OAuth security considerations . . . . . . . . . . . . . . 9 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 9. Revision History . . . . . . . . . . . . . . . . . . . . . . . 10 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 10.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Appendix A. Notes on implementing base64url encoding without paddi 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 Public clients in OAuth 2.0 [RFC6749] are susceptible to the 88 authorization "code" interception attack. A malicious client 89 intercepts the authorization code returned from the authorization 90 endpoint within communication path not protected by TLS, such as 91 inter-app communication, and uses it to obtain the access token. 92 This is possible on a public client as there is no client secret 93 associated for it to be sent to the token endpoint. This is 94 especially true on Smartphone applications where the authorization 95 code can be returned through custom URL Schemes where the same scheme 96 can be registered by multiple applications. Under this scenario, the 97 mitigation strategy stated in section 4.4.1 of [RFC6819] does not 98 work as they rely on per-client instance secret or per client 99 instance redirect URI. 101 To mitigate this attack, this extension utilizes a dynamically 102 created cryptographically random key called 'code verifier'. The code 103 verifier is created for every authorization request and its 104 transformed value, called 'code challenge', is sent to the 105 authorization server to obtain the authorization code. The 106 authorization "code" obtained is then sent to the token endpoint with 107 the 'code verifier' and the server compares it with the previously 108 received request code so that it can perform the proof of possession 109 of the 'code verifier' by the client. This works as the mitigation 110 since the attacker would not know this one-time key. 112 1.1. Protocol Flow 114 +--------+ +---------------+ 115 | |--(A)-- Authorization Request --->| | 116 | | + t(code_verifier), t | Resource | 117 | | | Owner | 118 | |<-(B)--- Authorization Grant -----| | 119 | | +---------------+ 120 | Client | 121 | | +---------------+ 122 | |--(C)--- Access Token Request --->| | 123 | | + code_verifier | Authorization | 124 | | | Server | 125 | |<-(D)------ Access Token ---------| | 126 +--------+ +---------------+ 128 This specification adds additional parameters to the OAuth 2.0 129 Authorization and Access Token Requests, shown in abstract form in 130 Figure 1. 132 A. The client creates and records a secret named the "code_verifier", 133 and derives a transformed version "t(code_verifier)" (referred to 134 as the "code_challenge") which is sent in the OAuth 2.0 135 Authorization Request, along with the transformation method "t". 136 B. The resource owner responds as usual, but records 137 "t(code_verifier)" and the transformation method. 138 C. The client then sends the code to the Access Token Request as 139 usual, but includes the "code_verifier" secret generated at (A). 140 D. The authorization server transforms "code_verifier" and compares 141 it to "t(code_verifier)" from (B). Access is denied if they are 142 not equal. 144 An attacker who intercepts the Authorization Grant at (B) is unable 145 to redeem it for an Access Token, as they are not in possession of 146 the "code_verifier" secret. 148 2. Notational Conventions 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in Key 152 words for use in RFCs to Indicate Requirement Levels [RFC2119]. If 153 these words are used without being spelled in uppercase then they are 154 to be interpreted with their normal natural language meanings. 156 This specification uses the Augmented Backus-Naur Form (ABNF) 157 notation of [RFC5234]. 159 BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per 160 Section 3 producing a [US-ASCII] STRING. 162 BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, 163 per Section 3, producing a UTF-8 sequence of octets. 165 SHA256(STRING) denotes a SHA2 256bit hash [RFC4634] of STRING. 167 UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation 168 of STRING. 170 ASCII(STRING) denotes the octets of the ASCII [US-ASCII] 171 representation of STRING. 173 The concatenation of two values A and B is denoted as A || B. 175 3. Terminology 177 In addition to the terms defined in OAuth 2.0 [RFC6749], this 178 specification defines the following terms: 180 code verifier A cryptographically random string that is used to 181 correlate the authorization request to the token request. 182 code challenge A challenge derived from the code verifier that is 183 sent in the authorization request, to be verified against later. 184 Base64url Encoding Base64 encoding using the URL- and filename-safe 185 character set defined in Section 5 of RFC 4648 [RFC4648], with all 186 trailing '=' characters omitted (as permitted by Section 3.2) and 187 without the inclusion of any line breaks, whitespace, or other 188 additional characters. (See Appendix Appendix A for notes on 189 implementing base64url encoding without padding.) 191 4. Protocol 193 4.1. Client creates a code verifier 195 The client first creates a code verifier, "code_verifier", for each 196 OAuth 2.0 [RFC6749] Authorization Request, in the following manner: 198 code_verifier = high entropy cryptographic random [US-ASCII] sequence 199 using the url and filename safe Alphabet [A-Z] / [a-z] / [0-9] / "-" 200 / "_" from Sec 5 of RFC 4648 [RFC4648], with length less than 128 201 characters. 203 ABNF for "code_verifier" is as follows. 205 code_verifier = 42*128unreserved 206 unreserved = [A-Z] / [a-z] / [0-9] / "-" / "_" 208 NOTE: code verifier SHOULD have enough entropy to make it impractical 209 to guess the value. It is RECOMMENDED that the output of a suitable 210 random number generator be used to create a 32-octet sequence. The 211 Octet sequence is then BASE64URL encoded to produce a 42-octet URL 212 safe string to use as the code verifier. 214 4.2. Client creates the code challenge 216 The client then creates a code challenge, "code_challenge", derived 217 from the "code_verifier" by using one of the following 218 transformations on the "code_verifier": 220 plain "code_challenge" = "code_verifier" 221 S256 "code_challenge" = BASE64URL(SHA256("code_verifier")) 223 It is RECOMMENDED to use the S256 transformation when possible. 225 ABNF for "code_challenge" is as follows. 227 code_challenge = 42*128unreserved 228 unreserved = [A-Z] / [a-z] / [0-9] / "-" / "_" 230 4.3. Client sends the code challenge with the authorization request 232 The client sends the code challenge as part of the OAuth 2.0 233 [RFC6749] Authorization Request (Section 4.1.1.) using the following 234 additional parameters: 236 code_challenge REQUIRED. Code challenge. 238 code_challenge_method OPTIONAL, defaults to "plain". Code verifier 239 transformation method, "S256" or "plain". 241 4.4. Server returns the code 243 When the server issues the "code" in the Authorization Response, it 244 MUST associate the "code_challenge" and "code_challenge_method" 245 values with the "code" so it can be verified later. 247 Typically, the "code_challenge" and "code_challenge_method" values 248 are stored in encrypted form in the "code" itself, but could 249 alternatively be stored on the server, associated with the code. The 250 server MUST NOT include the "code_challenge" value in client requests 251 in a form that other entities can extract. 253 The exact method that the server uses to associate the 254 "code_challenge" with the issued "code" is out of scope for this 255 specification. 257 4.4.1. Error Response 259 If the server requires SPOP, and the client does not send the 260 "code_challenge" in the request, the authorization endpoint MUST 261 return the authorization error response with "error" value set to 262 "invalid_request" and "error_description" or "error_uri" whose 263 content explaining the nature of error. 265 If the server supporting SPOP only supports "S256", and the client 266 requests plain transformation, the authorization endpoint MUST return 267 the authorization error response with "error" value set to 268 "unsupported_spop_transform". The "error_description" or the 269 response of "error_uri" SHOULD explain the nature of error, e.g., 270 transform algorithm not supported. 272 If the client is capable of using "S256", it MUST use "S256", as 273 "S256" is MTI on the server. Clients MAY use plain only if they 274 cannot support "S256" for some technical reason and knows that the 275 server supports "plain". 277 4.5. Client sends the code and the secret to the token endpoint 279 Upon receipt of the "code", the client sends the Access Token Request 280 to the token endpoint. In addition to the parameters defined in 281 OAuth 2.0 [RFC6749] Access Token Request (Section 4.1.3.), it sends 282 the following parameter: 284 code_verifier REQUIRED. Code verifier 286 4.6. Server verifies code_verifier before returning the tokens 288 Upon receipt of the request at the Access Token endpoint, the server 289 verifies it by calculating the code challenge from received 290 "code_verifier" and comparing it with the previously associated 291 "code_challenge", after first transforming it according to the 292 "code_challenge_method" method specified by the client. 294 If the "code_challenge_method" from Section 4.2 was "S256", the 295 received "code_verifier" is first hashed with SHA-256 then compared 296 to the base64url decoded "code_challenge". i.e., 298 SHA256("code_verifier" ) == BASE64URL-DECODE("code_challenge"). 300 If the "code_challenge_method" from Section 4.2 was "plain", they are 301 compared directly. i.e., 303 "code_challenge" == "code_verifier". 305 If the values are equal, the Access Token endpoint MUST continue 306 processing as normal (as defined by OAuth 2.0 [RFC6749]). If the 307 values are not equal, an error response indicating "invalid_grant" as 308 described in section 5.2 of OAuth 2.0 [RFC6749] MUST be returned. 310 5. Compatibility 312 Server implementations of this specification MAY accept OAuth2.0 313 Clients that do not implement this extension. If the "code_verifier" 314 is not received from the client in the Authorization Request, servers 315 supporting backwards compatibility SHOULD revert to a normal OAuth 316 2.0 [RFC6749] protocol. 318 As the OAuth 2.0 [RFC6749] server responses are unchanged by this 319 specification, client implementations of this specification do not 320 need to know if the server has implemented this specification or not, 321 and SHOULD send the additional parameters as defined in Section 3. to 322 all servers. 324 6. IANA Considerations 326 This specification makes a registration request as follows: 328 6.1. OAuth Parameters Registry 330 This specification registers the following parameters in the IANA 331 OAuth Parameters registry defined in OAuth 2.0 [RFC6749]. 333 o Parameter name: code_verifier 334 o Parameter usage location: Access Token Request 335 o Change controller: IESG 336 o Specification document(s): this document 338 o Parameter name: code_challenge 339 o Parameter usage location: Authorization Request 340 o Change controller: IESG 341 o Specification document(s): this document 343 o Parameter name: code_challenge_method 344 o Parameter usage location: Authorization Request 345 o Change controller: IESG 346 o Specification document(s): this document 348 6.2. SPOP Code Challenge Method Registry 350 This specification establishes the SPOP Code Challenge Method 351 registry. 353 Additional code_challenge_method types for use with the authorization 354 endpoint are registered with a Specification Required ([RFC5226]) 355 after a two-week review period on the oauth-ext-review@ietf.org 356 mailing list, on the advice of one or more Designated Experts. 357 However, to allow for the allocation of values prior to publication, 358 the Designated Expert(s) may approve registration once they are 359 satisfied that such a specification will be published. 361 Registration requests must be sent to the oauth-ext-review@ietf.org 362 mailing list for review and comment, with an appropriate subject 363 (e.g., "Request for SPOP code_challenge_method: example"). 365 Within the review period, the Designated Expert(s) will either 366 approve or deny the registration request, communicating this decision 367 to the review list and IANA. Denials should include an explanation 368 and, if applicable, suggestions as to how to make the request 369 successful. 371 IANA must only accept registry updates from the Designated Expert(s) 372 and should direct all requests for registration to the review mailing 373 list. 375 6.2.1. Registration Template 377 Code Challenge Method Parameter Name: 378 The name requested (e.g., "example"). Because a core goal of this 379 specification is for the resulting representations to be compact, 380 it is RECOMMENDED that the name be short -- not to exceed 8 381 characters without a compelling reason to do so. This name is 382 case-sensitive. Names may not match other registered names in a 383 case-insensitive manner unless the Designated Expert(s) state that 384 there is a compelling reason to allow an exception in this 385 particular case. 386 Change Controller: 387 For Standards Track RFCs, state "IESG". For others, give the name 388 of the responsible party. Other details (e.g., postal address, 389 email address, home page URI) may also be included. 390 Specification Document(s): 391 Reference to the document(s) that specify the parameter, 392 preferably including URI(s) that can be used to retrieve copies of 393 the document(s). An indication of the relevant sections may also 394 be included but is not required. 396 6.2.2. Initial Registry Contents 398 This specification registers the Code Challenge Method Parameter 399 names defined in Section 4.2 in this registry. 401 o Code Challenge Method Parameter Name: "plain" 402 o Change Controller: IESG 403 o Specification Document(s): Section 4.2 of [[ this document ]] 405 o Code Challenge Method Parameter Name: "S256" 406 o Change Controller: IESG 407 o Specification Document(s): Section 4.2 of [[ this document ]] 409 7. Security Considerations 411 7.1. Entropy of the code verifier 413 The security model relies on the fact that the code verifier is not 414 learned or guessed by the attacker. It is vitally important to 415 adhere to this principle. As such, the code verifier has to be 416 created in such a manner that it is cryptographically random and has 417 high entropy that it is not practical for the attacker to guess. It 418 is RECOMMENDED that the output of a suitable random number generator 419 be used to create a 32-octet sequence. 421 7.2. Protection against eavesdroppers 423 Clients MUST NOT try down grading the algorithm after trying "S256" 424 method. If the server is SPOP compliant, then "S256" method works. 425 If the server does not support SPOP, it does not generate error. 426 Only the time that the server returns that it does not support "S256" 427 is there is a MITM trying the algorithm downgrade attack. 429 "S256" method protects against eavesdroppers observing or 430 intercepting the "code_challenge". If the "plain" method is used, 431 there is a chance that it will be observed by the attacker on the 432 device. The use of "S256" protects against it. 434 If "code_challenge" is to be returned inside authorization "code" to 435 achieve a stateless server, it has to be encrypted in such a manner 436 that only the server can decrypt and extract it. 438 7.3. Checking the Server support 440 Before starting the authorization process, the client SHOULD check if 441 the server supports this specification. Confirmation of the server 442 support may be obtained out-of-band or through some other mechanisms 443 such as the discovery document in OpenID Connect Discovery 444 [OpenID.Discovery]. The exact mechanism on how the client obtains 445 this information, or the action it takes as a result is out of scope 446 of this specification. 448 7.4. OAuth security considerations 450 All the OAuth security analysis presented in [RFC6819] applies so 451 readers SHOULD carefully follow it. 453 8. Acknowledgements 455 The initial draft of this specification was created by the OpenID AB/ 456 Connect Working Group of the OpenID Foundation, most notably by the 457 following people: 459 o Naveen Agarwal, Google 460 o Dirk Balfanz, Google 461 o Sergey Beryozkin 462 o John Bradley, Ping Identity 463 o Brian Campbell, Ping Identity 464 o William Denniss, Google 465 o Eduardo Gueiros, Jive Communications 466 o Phil Hunt, Oracle 467 o Ryo Ito, mixi 468 o Michael B. Jones, Microsoft 469 o Torsten Lodderstedt, Deutsche Telekom 470 o Breno de Medeiros, Google 471 o Prateek Mishra, Oracle 472 o Anthony Nadalin, Microsoft 473 o Axel Nenker, Deutsche Telekom 474 o Nat Sakimura, Nomura Research Institute 476 9. Revision History 478 -05 480 o Added IANA registry for code_challenge_method + fixed some broken 481 internal references. 483 -04 485 o Added error response to authorization response. 487 -03 489 o Added an abstract protocol diagram and explanation 491 -02 493 o Copy edits 495 -01 497 o Specified exactly two supported transformations 498 o Moved discovery steps to security considerations. 499 o Incorporated readability comments by Eduardo Gueiros. 500 o Changed MUST in 3.1 to SHOULD. 502 -00 504 o Initial IETF version. 506 10. References 508 10.1. Normative References 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 514 10646", STD 63, RFC 3629, November 2003. 516 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 517 (SHA and HMAC-SHA)", RFC 4634, July 2006. 519 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 520 Encodings", RFC 4648, October 2006. 522 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 523 Specifications: ABNF", STD 68, RFC 5234, January 2008. 525 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 526 6749, October 2012. 528 [US-ASCII] 529 American National Standards Institute, "Coded Character 530 Set -- 7-bit American Standard Code for Information 531 Interchange", ANSI X3.4, 1986. 533 10.2. Informative References 535 [OpenID.Discovery] 536 Sakimura, N., Bradley, J., Jones, M.B. and E. Jay, "OpenID 537 Connect Discovery 1.0", February 2014. 539 [RFC6819] Lodderstedt, T., McGloin, M. and P. Hunt, "OAuth 2.0 540 Threat Model and Security Considerations", RFC 6819, 541 January 2013. 543 Appendix A. Notes on implementing base64url encoding without padding 545 This appendix describes how to implement base64url encoding and 546 decoding functions without padding based upon standard base64 547 encoding and decoding functions that do use padding. 549 To be concrete, example C# code implementing these functions is shown 550 below. Similar code could be used in other languages. 552 static string base64urlencode(byte [] arg) 553 { 554 string s = Convert.ToBase64String(arg); // Regular base64 encoder 555 s = s.Split('=')[0]; // Remove any trailing '='s 556 s = s.Replace('+', '-'); // 62nd char of encoding 557 s = s.Replace('/', '_'); // 63rd char of encoding 558 return s; 559 } 561 static byte [] base64urldecode(string arg) 562 { 563 string s = arg; 564 s = s.Replace('-', '+'); // 62nd char of encoding 565 s = s.Replace('_', '/'); // 63rd char of encoding 566 switch (s.Length % 4) // Pad with trailing '='s 567 { 568 case 0: break; // No pad chars in this case 569 case 2: s += "=="; break; // Two pad chars 570 case 3: s += "="; break; // One pad char 571 default: throw new System.Exception( 572 "Illegal base64url string!"); 573 } 574 return Convert.FromBase64String(s); // Standard base64 decoder 575 } 577 As per the example code above, the number of '=' padding characters 578 that needs to be added to the end of a base64url encoded string 579 without padding to turn it into one with padding is a deterministic 580 function of the length of the encoded string. Specifically, if the 581 length mod 4 is 0, no padding is added; if the length mod 4 is 2, two 582 '=' padding characters are added; if the length mod 4 is 3, one '=' 583 padding character is added; if the length mod 4 is 1, the input is 584 malformed. 586 An example correspondence between unencoded and encoded values 587 follows. The octet sequence below encodes into the string below, 588 which when decoded, reproduces the octet sequence. 590 3 236 255 224 193 592 A-z_4ME 594 Authors' Addresses 596 Nat Sakimura, editor 597 Nomura Research Institute 598 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. 599 Chiyoda-ku, Tokyo 100-0005 600 Japan 602 Phone: +81-3-5533-2111 603 Email: n-sakimura@nri.co.jp 604 URI: http://nat.sakimura.org/ 605 John Bradley 606 Ping Identity 607 Casilla 177, Sucursal Talagante 608 Talagante, RM 609 Chile 611 Phone: +44 20 8133 3718 612 Email: ve7jtb@ve7jtb.com 613 URI: http://www.thread-safe.com/ 615 Naveen Agarwal 616 Google 617 1600 Amphitheatre Pkwy 618 Mountain View, CA 94043 619 USA 621 Phone: +1 650-253-0000 622 Email: naa@google.com 623 URI: http://google.com/