idnits 2.17.1 draft-harkins-owe-06.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 -- The document date (January 23, 2017) is 2643 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SEC1' is mentioned on line 547, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harkins, Ed. 3 Internet-Draft HP Enterprise 4 Intended status: Informational W. Kumari, Ed. 5 Expires: July 27, 2017 Google 6 January 23, 2017 8 Opportunistic Wireless Encryption 9 draft-harkins-owe-06 11 Abstract 13 This memo specifies an extension to IEEE Std 802.11 to provide for 14 opportunistic (unauthenticated) encryption to the wireless media. 16 [ Ed note: Text inside square brackets ([]) is additional background 17 information, answers to frequently asked questions, general musings, 18 etc. They will be removed before publication. This document is 19 being collaborated on in Github at: https://github.com/wkumari/draft- 20 harkins-owe. The authors (gratefully) accept pull requests. ] 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 27, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 58 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.3. Why IETF? . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. 802.11 Network Access . . . . . . . . . . . . . . . . . . . . 4 62 4. Opportunistic Wireless Encryption . . . . . . . . . . . . . . 5 63 4.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. OWE Discovery . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. OWE Association . . . . . . . . . . . . . . . . . . . . . 6 66 4.4. OWE Post-Association . . . . . . . . . . . . . . . . . . 8 67 4.5. OWE PMK Caching . . . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 6. Implementation Considerations . . . . . . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 8.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 This memo describes a mode of opportunistic security [RFC7435] for 80 802.11 -- OWE -- that provides encryption of the wireless medium but 81 no authentication. 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 1.2. Notation 91 This memo uses the following notation: 93 y = F(X) an element-to-scalar mapping function. For an elliptic 94 curve group, it takes a point on the curve and returns the 95 x-coordinate; for a finite field element it is the identity 96 function, just returning the element itself. 98 Z = DH(x,Y) 99 for an elliptic curve DH(x,Y) is the multiplication of point Y by 100 the scalar value x creating a point on the curve Z; for finite 101 field cryptography DH(x,Y) is expontiation of element Y to the 102 power of x (implied modulo a field defining prime, p) resulting 103 in an element Z. 105 a = len(b) 106 indicates the length in bits of the string b. 108 1.3. Why IETF? 110 [ RFC Editor: Please remove this entire section before publication. 112 The protocol described here is an extension to the IEEE 802.11 113 standard and the question, naturally, arises: why do this in the 114 IETF? 116 As the name implies, OWE provides opportunistic encryption, or 117 encryption of traffic without authentication of endpoints. OWE was 118 presented to the IEEE 802.11 Working Group for consideration but an 119 "all or nothing" approach to cryptographic protection has been 120 adopted by that body, and OWE is a stop in between "all" and 121 "nothing". 123 Through documents such as [RFC7435] and [RFC5386] the IETF has been 124 at the forefront of expanding the use of encryption in the Internet, 125 even when authentication is not possible or practical. The IETF is a 126 natural home for OWE. 128 This topic has been discussed within the IEEE IETF Coordination group 129 (notes from meeting: https://www.ietf.org/mail-archive/web/ieee-ietf- 130 coord/current/msg00828.html), and within the IEEE. The IEEE has 131 allocated codepoints for this technique, see: 132 http://www.ieee802.org/11/email/stds-802-11-editors/msg00209.html ] 134 2. Background 136 Internet access has become an expected service at many locations - 137 for example, coffee shops, airports and hotels. In many cases, this 138 is offered over "Open" (unencrypted) wireless networks, because 139 distributing a passphrase (or using other authentication solutions) 140 is not convenient or realistic. Ideally, users would always use a 141 VPN when using an untrusted network, but often they don't. This 142 leaves their traffic vulnerable to sniffing attacks, for example from 143 someone in the adjacent hotel room running Wireshark, pervasive 144 monitors, etc. 146 In addition, many businesses (for example, coffee shops and bars) 147 offer free Wi-Fi as an inducement to customers to enter and remain in 148 the premises. Many customers will use the availability of free Wi-Fi 149 as a deciding factor in which business to patronize. Since these 150 businesses are not Internet service providers, they are often 151 unwilling and/or unqualified to perform complex configuration on 152 their network. In addition, customers are generally unwilling to do 153 complicated provisioning on their devices just to obtain free Wi-Fi. 154 This leads to a popular deployment technique -- a network protected 155 using a shared and public PSK that is printed on a sandwich board at 156 the entrance, on a chalkboard on the wall, or on a menu. The PSK is 157 used in a cryptographic handshake defined in [IEEE802.11] called the 158 "4-way handshake" to prove knowledge of the PSK and derive traffic 159 encryption keys for bulk wireless data. 161 The belief is that this protects the wireless medium from passive 162 sniffing and simple attacks. That belief is erroneous. Since the 163 PSK is known by everyone, it is possible for a passive attacker to 164 observe the 4-way Handshake and compute the traffic encryption keys 165 used by a client and access point. If the attacker is too late to 166 observe this exchange, he can issue a forged "de-authenticate" frame 167 that will cause the client and/or AP to reset the 802.11 state 168 machine and cause them to go through the 4-way Handshake again 169 thereby allowing the passive attacker to determine the traffic keys. 171 With OWE, the client and AP, perform a Diffie-Hellman key exchange 172 during the access procedure and use the resulting pairwise secret 173 with the 4-way Handshake, instead of using a shared and public PSK in 174 the 4-way Handshake. 176 OWE requires no special configuration or user interaction but 177 provides a higher level of security than a common, shared, and public 178 PSK. OWE not only provides more security to the end user, it is also 179 easier to use both for the provider and the end user -- there are no 180 public keys to maintain, share, or manage. 182 3. 802.11 Network Access 184 Wi-Fi Access Points (AP) advertise their presence through frames 185 called "beacons". These frames inform clients within earshot of the 186 SSID (Service Set Identifier) the AP is advertising, the AP's MAC 187 address (known as its "BSSID" (Basic Service Set Identifier)), 188 security policy governing access, which symmetric ciphers it uses for 189 unicast and broadcast frames, QoS information, as well as support for 190 other optional features of [IEEE802.11]. Wi-Fi clients can actively 191 discover APs by issuing "probe requests" which are queries for APs 192 that respond with "probe responses". A probe response carries 193 essentially the same information as a beacon. 195 After an AP is discovered by a client, actively through probing or 196 passively through beacons, the client initiates a two-step method to 197 gain network access. The first step is "802.11 authentication". For 198 most methods of access (SAE being the exception), this is an empty 199 exchange known as "Open Authentication-- basically the client says, 200 "authenticate me", and the AP responds "ok, you're authenticated". 201 After 802.11 authentication is 802.11 association, in which the 202 client requests network access from an AP-- the SSID, a selection of 203 the type of subsequent authentication to be made, any pairwise and 204 group ciphers, etc-- using an 802.11 association request. The AP 205 acknowledges the request with an 802.11 association response. 207 If the network is Open-- no authentication, no encryption-- the 208 client has network access immediately after completion of 802.11 209 association. If the network enforces PSK authentication, the 4-way 210 Handshake is initiated by the AP using the PSK to authenticate the 211 client and derive traffic encryption keys. 213 To add an opportunistic encryption mode of access to [IEEE802.11], it 214 is necessary to perform a Diffie-Hellman key exchange during 802.11 215 authentication and use the resulting pairwise secret with the 4-way 216 Handshake. 218 4. Opportunistic Wireless Encryption 220 4.1. Cryptography 222 Performing a Diffie-Hellman key exchange requires agreement on a 223 domain parameter set in which to perform the exchange. OWE uses a 224 registry (see [IKE-IANA]) to map an integer into a complete domain 225 parameter set. OWE supports both elliptic curve cryptography (ECC) 226 and finite field cryptography (FFC). 228 OWE uses a hash algorithm for generation of a secret and a secret 229 identifier. The particular hash algorithm depends on the group 230 chosen for the Diffie-Hellman. For ECC, the hash algorithm depends 231 on the size of the prime defining the curve, p: 233 o SHA-256: when len(p) <= 256 235 o SHA-384: when 256 < len(p) <= 384 237 o SHA-512: when 384 < len(p) 239 For FFC, the hash algorithm depends on the prime, p, defining the 240 finite field: 242 o SHA-256: when len(p) <= 2048 243 o SHA-384: when 2048 < len(p) <= 3072 245 o SHA-512: when 3072 < len(p) 247 4.2. OWE Discovery 249 An access point advertises support for OWE using an Authentication 250 and Key Management (AKM) suite selector for OWE. This AKM is 251 illustrated in Table 1 and is added to the RSN element in all Beacons 252 and Probe Response frames that the AP issues. 254 OWE AKM 256 +----------+--------+-------------------+-------------+-------------+ 257 | OUI | Suite | Authentication | Key | Key | 258 | | Type | Type | Management | derivation | 259 | | | | Type | type | 260 +----------+--------+-------------------+-------------+-------------+ 261 | 00-0F-AC | 18 | Opportunistic | This | [RFC5869] | 262 | | | Wireless | document | | 263 | | | Encryption | | | 264 +----------+--------+-------------------+-------------+-------------+ 266 Table 1: OWE AKM 268 Once a client discovers an OWE-compliant AP, it performs "Open 269 System" 802.11 authentication as defined in [IEEE802.11], it then 270 proceeds to 802.11 association. 272 4.3. OWE Association 274 Information is added to 802.11 association requests and responses by 275 using TLVs that [IEEE802.11] calls "elements". Each element has an 276 "Element ID" (including any Element ID extension), a length, and a 277 value field that is element-specific. These elements are appended to 278 each other to construct 802.11 associate requests and responses. 280 OWE adds the Diffie-Hellman Parameter element (see Figure 1) to 281 802.11 association requests and responses. The client adds her 282 public key in the 802.11 associate request and the AP adds his public 283 key in the 802.11 associate response. 285 The Diffie-Hellman Parameter Element 287 +------------+----------+------------+------------------------+ 288 | Element ID | Length | Element ID | element-specific | 289 | | | Extension | data | 290 +------------+----------+------------+---------+--------------+ 291 | 255 | variable | 32 | group | public key | 292 +------------+----------+------------+---------+--------------+ 294 Figure 1 296 where 298 o group is an unsigned two-octet integer defined in [IKE-IANA], in 299 little-endian format, that identifies a domain parameter set; 301 o public key is an octet string representing the Diffie-Hellman 302 public key; and, 304 o Element ID, Length, and ID Extension are all single octet integers 305 in little-endian format. 307 The encoding of the public key depends on its type. FFC elements 308 SHALL be encoded per the integer-to-Octet-String conversion technique 309 of [RFC6090]. For ECC elements, the encoding depends on the 310 definition of the curve, either [RFC6090] or [RFC7748]. If the 311 public key is from a curve defined in [RFC6090], compact 312 representation SHALL be used. 314 A client wishing to do OWE MUST indicate the OWE AKM in the RSN 315 element portion of the 802.11 association request, and MUST include a 316 Diffie-Hellman Parameter element to its 802.11 association request. 317 An AP agreeing to do OWE MUST include the OWE AKM in the RSN element 318 portion of the 802.11 association response. If "PMK caching" (see 319 Section 4.5) is not performed, it MUST also include a Diffie-Hellman 320 Parameter element. If "PMK caching" is not being performed, a client 321 MUST discard any 802.11 association response that indicates the OWE 322 AKM in the RSN element but does not have not a Diffie-Hellman 323 Parameter element. 325 For interoperability purposes, a compliant implementation MUST 326 support group nineteen (19), a 256-bit elliptic curve group. If the 327 AP does not support the group indicated in the received 802.11 328 association request it MUST respond with an 802.11 association 329 response with a status code of seventy-seven (77) indicating an 330 unsupported finite cyclic group. A client that receives an 802.11 331 association response with a status code of seventy-seven SHOULD retry 332 OWE with a different supported group and, due to the unsecured nature 333 of 802.11 association, MAY request association again using the group 334 which resulted in failure. This failure SHOULD be logged and if the 335 client abandons association due to the failure to agree on any group, 336 notification of this fact SHOULD be provided to the user. 338 Received Diffie-Hellman Parameter Elements are checked for validity 339 upon receipt. For ECC, a validity check depends on the curve 340 definition, either [RFC6090] or [RFC7748]. For FFC, elements are 341 checked that they are between one (1) and one (1) less than the 342 prime, p, exclusive (i.e. 1 < element < p-1). Invalid received 343 Diffie-Hellman keys MUST result in unsuccessful association, a 344 failure of OWE, and resetting of the 802.11 state machine. Due to 345 the unsecured nature of 802.11 association a client SHOULD retry OWE 346 a number of times (which this memo does not specify). This failure 347 should be logged and if the client abandons association due to the 348 (repeated) receipt of invalid elements, notification of this fact 349 should be provided to the user. 351 4.4. OWE Post-Association 353 Once the client and AP have finished 802.11 association, they then 354 complete the Diffie-Hellman key exchange and create a "pairwise 355 master key" (PMK), and its associated identifier, PMKID. Given a 356 private key x, and the peer's (AP's if client, client's if AP) public 357 key Y the following are generated: 359 z = F(DH(x, Y)) 361 prk = HKDF-extract(C | A | group, z) 363 PMK = HKDF-expand(prk, "OWE Key Generation", n) 365 Where HKDF-expand() and HKDF-extract() are defined in [RFC5869]; "C | 366 A | group" is a concatentation of the client's Diffie-Hellman public 367 value, the AP's Diffie-Hellman public value (from the 802.11 368 Associate Request and Response, respectively), and the two-octet 369 group from the Diffie-Hellman Parameter element (in little-endian 370 format) and is passed as the salt to HKDF using the hash algorithm 371 defined in section Section 4.1; and, n is the bit-length of the 372 digest produced by that hash algorithm. z and prk SHOULD be 373 irretrievably deleted once the PMK has been generated. 375 The PMKID is generated by hashing the two Diffie-Hellman public keys 376 (the data, as sent and received, from the "public key" portion of the 377 Diffie-Hellman Parameter element in the 802.11 Association request 378 and response) and returning the left-most 128 bits: 380 PMKID = Truncate-128(Hash(C | A)) 382 where C is the client's Diffie-Hellman public key from the 802.11 383 Association request and A is the AP's Diffie-Hellman public key from 384 the 802.11 Association response, and Hash is the hash algorithm 385 defined in section Section 4.1. 387 Upon completion of 802.11 association, the AP initiates the 4-way 388 Handshake to the client using the PMK generated above. The result of 389 the 4-way Handshake is encryption keys to protect bulk unicast data 390 and broadcast data. If the 4-way Handshake fails this information 391 SHOULD be presented to the user. 393 4.5. OWE PMK Caching 395 [IEEE802.11] defines "PMK caching" where a client and access point 396 can cache a PMK for a certain period of time and reuse it with the 397 4-way Handshake after subsequent associations to bypass potentially 398 expensive authentication. A client indicates its desire to do "PMK 399 caching" by including the identifying PMKID in its 802.11 association 400 request. If an AP has cached the PMK identified by that PMKID, it 401 includes the PMKID in its 802.11 association response, otherwise it 402 ignores the PMKID and proceeds with normal 802.11 association. OWE 403 supports the notion of "PMK caching". 405 Since "PMK caching" is indicated in the same frame as the Diffie- 406 Hellman Parameter element is passed, a client wishing to do "PMK 407 caching" MUST include both in her 802.11 association request. If the 408 AP has the PMK identified by the PMKID and wishes to perform "PMK 409 caching", he will include the PMKID in his 802.11 association 410 response but does not include a Diffie-Hellman parameter element. If 411 the AP does not have the PMK identified by the PMKID, it ignores the 412 PMKID and proceeds with normal OWE 802.11 association by including a 413 Diffie-Hellman Parameter element. 415 When attempting "PMK caching" a client SHALL ignore any Diffie- 416 Hellman Parameter element in an 802.11 association response that 417 whose PMKID matches that of the client-issued 802.11 association 418 request. If the 802.11 association response does not include a 419 PMKID, or if the PMKID does not match that of the client-issued 420 802.11 association request, the client SHALL proceed with normal OWE 421 association. 423 The client SHALL ignore a PMKID in any 802.11 association response 424 frame for which it did not include a PMKID in the corresponding 425 802.11 association request frame. 427 5. IANA Considerations 429 This memo includes no request to IANA. 431 6. Implementation Considerations 433 OWE is a replacement for 802.11 "Open" authentication. Therefore, 434 when OWE-compliant access points are discovered, the presentation of 435 the available SSID to users should not include special security 436 symbols such as a "lock icon". To a user, an OWE SSID is the same as 437 "Open", it simply provides more security behind the scenes. 439 When OWE is initially deployed as a replacement for an existing 440 network that uses "Open" authentication or a shared and public PSK it 441 will be necessary to create an additional Basic Service Set 442 identifier (BSSID) or a new Extended Service Set (ESS) with a 443 separate Service Set Identifier (SSID) for OWE so two distinct 802.11 444 networks can exist on the same Access Point (see [IEEE802.11]). This 445 arrangement should remain until the majority of users have switched 446 over to OWE. 448 7. Security Considerations 450 Opportunistic encryption does not provide authentication. The client 451 will have no authenticated identity for the Access Point, and vice 452 versa. They will share pairwise traffic encryption keys and have a 453 cryptographic assurance that a frame claimed to be from the peer is 454 actually from the peer and was not modified in flight. 456 OWE only secures data sent over the wirless medium and does not 457 provide security for end-to-end traffic. Users should still use 458 application-level security for achieve security end-to-end. 460 OWE is susceptible to an active attack in which an adversary 461 impersonates an Access Point, induces a client to connect to it via 462 OWE while it makes a connection to the legitimate Access Point. In 463 this particular attack, the adversary is able to inspect, modify, and 464 forge any data between the client and legitimate Access Point. 466 OWE is not a replacement for any authentication protocol specified in 467 [IEEE802.11] and is not intended to be used when an alternative that 468 provides real authentication is available. 470 8. References 471 8.1. Normative References 473 [IEEE802.11] 474 IEEE Computer Society, "Telecommunications and information 475 exchange between systems Local and metropolitan area 476 networks--", Part 11: Wireless LAN Medium Access Control 477 (MAC) and Physical Layer (PHY) Specifications IEEE Std 478 802.11-2016, 2016. 480 [IKE-IANA] 481 IANA, "Internet Key Exchange (version 2) Parameters", 482 Transform Type 4: Diffie-Hellman Group Transform IDs, 483 2005, . 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 490 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 491 RFC5869, May 2010, 492 . 494 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 495 Curve Cryptography Algorithms", RFC 6090, February 2011. 497 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 498 for Security", RFC 7748, DOI 10.17487/RFC7748, January 499 2016, . 501 8.2. Informative References 503 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 504 Security: An Unauthenticated Mode of IPsec", RFC 5386, DOI 505 10.17487/RFC5386, November 2008, 506 . 508 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 509 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 510 December 2014, . 512 Appendix A. Changes / Author Notes. 514 [ RFC Editor: Please remove this section befor publication ] 516 -00: 518 Initial version. 520 -00 to -01: 522 Editorial, title change. 524 -01 to -02: 526 Stressed the use of this as an alternative to "Open", not PSK. 527 The PSK case is more interesting to discuss, but Open is more 528 widely applicable. 530 -02 to -03: 532 Added "Why IETF?" 534 -03 to -04: 536 Closed the "False sense of security" TODO - it was already done 537 (above). 539 Filled in the ANA-1 and ANA-2 placeholders with the actual values. 541 Closed the "failure to agree on group" TODO. 543 -04 to -05: 545 Closed the "what to do if invalid elements are received" TODO. 547 Closed the "is [SEC1] a good and stable reference?" comment. 549 Closed the "what about curve25519?" comment. 551 Closed the "should the group be included in PMK derivation? 552 comment. 554 Closed the issue regarding validity checks for curve25519. 556 -05 to -06: 558 Changed 802.11 reference to -2016 since that just came out. 560 Added note in Security Considerations on end-to-end security (Lucy 561 Yong comment). 563 Added note about using a 2nd BSSID or SSID when transitioning to 564 OWE (Mahesh Jethanandani comment). 566 Added note about alerting the user to a failure of the 4-way 567 Handshake (Mahesh Jethanandani comment). 569 s/suite identifier/suite selector/ in 4.2 (Robert Stacey comment). 571 3rd column in Figure 1 should be "Element ID Extension" (Robert 572 Stacey comment). 574 Conformed to IEEE 802.11 style wrt capitalization in 4.2 (Robert 575 Stacey comment). 577 Authors' Addresses 579 Dan Harkins (editor) 580 HP Enterprise 581 1322 Crossman avenue 582 Sunnyvale, California 94089 583 United States of America 585 Phone: +1 415 555 1212 586 Email: dharkins@arubanetworks.com 588 Warren Kumari (editor) 589 Google 590 1600 Amphitheatre Parkway 591 Mountain View, California 94043 592 United States of America 594 Phone: +1 408 555 1212 595 Email: warren@kumari.net