idnits 2.17.1 draft-ietf-emu-eaptunnel-req-09.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 175: '... MUST - indicates an absolute req...' RFC 2119 keyword, line 177: '... MUST NOT - indicates something a...' RFC 2119 keyword, line 179: '... SHOULD - indicates a strong reco...' RFC 2119 keyword, line 181: '... SHOULD NOT - indicates a strong ...' RFC 2119 keyword, line 183: '... MAY - indicates a willingness to...' (97 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 16, 2010) is 4879 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-emu-chbind-06 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU Working Group K. Hoeper 3 Internet-Draft Motorola, Inc. 4 Intended status: Informational S. Hanna 5 Expires: June 19, 2011 Juniper Networks 6 H. Zhou 7 J. Salowey, Ed. 8 Cisco Systems, Inc. 9 December 16, 2010 11 Requirements for a Tunnel Based EAP Method 12 draft-ietf-emu-eaptunnel-req-09.txt 14 Abstract 16 This memo defines the requirements for a tunnel-based Extensible 17 Authentication Protocol (EAP) Method. This tunnel method will use 18 Transport Layer Security (TLS) to establish a secure tunnel. The 19 tunnel will provide support for password authentication, EAP 20 authentication and the transport of additional data for other 21 purposes. 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 June 19, 2011. 40 Copyright Notice 42 Copyright (c) 2010 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 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Conventions Used In This Document . . . . . . . . . . . . . . 5 73 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1. Password Authentication . . . . . . . . . . . . . . . . . 6 75 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 6 76 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 7 77 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 7 78 3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7 79 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 8 80 3.7. Client Authentication During Tunnel Establishment . . . . 8 81 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 82 3.9. Certificate-less Authentication and Generic EAP Method 83 Extension . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9 87 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9 88 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10 89 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10 90 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10 91 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10 92 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 11 93 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11 94 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12 95 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12 96 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 97 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 98 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 99 4.2.3. Protection of Data External to Tunnel . . . . . . . . 13 100 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 13 101 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13 102 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 103 4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13 104 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 105 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 14 106 4.3.6. Internationalization of Display Strings . . . . . . . 14 107 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 108 4.5. Requirements Associated with Carrying Username and 109 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 110 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 15 111 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 15 112 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 113 4.5.1.3. Server Certificate Revocation Checking . . . . . . 15 114 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 115 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 16 116 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 16 117 4.6. Requirements Associated with Carrying EAP Methods . . . . 16 118 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 119 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 120 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16 121 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 18 122 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 18 124 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 126 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 127 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18 128 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 129 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 20 130 6.4. Separation of TLS Tunnel and Inner Authentication 131 Termination . . . . . . . . . . . . . . . . . . . . . . . 20 133 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 134 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 135 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 137 Appendix A. Changes from -01 . . . . . . . . . . . . . . . . . . 23 139 Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 23 141 Appendix C. changes from -03 . . . . . . . . . . . . . . . . . . 23 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 145 1. Introduction 147 An Extensible Authentication Protocol (EAP) tunnel method is an EAP 148 method that establishes a secure tunnel and executes other EAP 149 methods under the protection of that secure tunnel. An EAP tunnel 150 method can be used in any lower layer protocol that supports EAP 151 authentication. There are several existing EAP tunnel methods that 152 use Transport Layer Security (TLS) to establish the secure tunnel. 153 EAP methods supporting this include Protected EAP (PEAP) [PEAP], 154 Tunneled Transport Layer Security EAP (TTLS) [RFC5281] and EAP 155 Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. 156 In general this has worked well so there is consensus to continue to 157 use TLS as the basis for a tunnel method. There have been various 158 reasons for employing a protected tunnel for EAP processes. They 159 include protecting weak authentication exchanges, such as username 160 and password. In addition a protected tunnel can provide means to 161 provide peer identity protection and EAP method chaining. Finally, 162 systems have found it useful to transport additional types of data 163 within the protected tunnel. 165 This document describes the requirements for a EAP tunnel method as 166 well as for a password protocol supporting legacy password 167 verification within the tunnel method. 169 2. Conventions Used In This Document 171 Use of each capitalized word within a sentence or phrase carries the 172 following meaning during the EAP Method Update (EMU) WG's method 173 selection process: 175 MUST - indicates an absolute requirement 177 MUST NOT - indicates something absolutely prohibited 179 SHOULD - indicates a strong recommendation of a desired result 181 SHOULD NOT - indicates a strong recommendation against a result 183 MAY - indicates a willingness to allow an optional outcome 185 Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and 186 "MAY" carry their normal meaning and are not subject to these 187 definitions. 189 3. Use Cases 191 To motivate and explain the requirements in this document, a 192 representative set of use cases for the EAP tunnel method are 193 supplied here. It is mandatory for a candidate tunnel method to 194 support all of the use cases that are marked below as "MUST". 196 3.1. Password Authentication 198 Many legacy systems only support user authentication with passwords. 199 Some of these systems require transport of the actual username and 200 password to the authentication server. This is true for systems 201 where the authentication server does not have access to the cleartext 202 password or a consistent transform of the cleartext password. 203 Example of such systems are some one time password (OTP) systems and 204 other systems where the username and password are submitted to an 205 external party for validation. The tunnel method MUST support 206 transporting cleartext username and password to the EAP server. It 207 MUST NOT reveal information about the username and password to 208 parties in the communication path between the peer and the EAP 209 Server. The advantage any attacker gains against the tunnel method 210 when employing a username and password for authentication MUST be 211 through interaction and not computation. The tunnel MUST support 212 protection from man-in-the-middle attacks. The combination of the 213 tunnel authentication and password authentication MUST enable mutual 214 authentication. 216 Since EAP authentication occurs before network access is granted the 217 tunnel method SHOULD enable an inner exchange to provide support for 218 minimal password management tasks including password change, "new PIN 219 mode", and "next token mode" required by some systems. 221 3.2. Protection of Weak EAP Methods 223 Some existing EAP methods have vulnerabilities that could be 224 eliminated or reduced by running them inside a protected tunnel. For 225 example, a EAP-MD5 does not provide mutual authentication or 226 protection from dictionary attacks. Without extra protection, EAP 227 tunnel methods are vulnerable to a special type of tunnel man-in-the- 228 middle attack [TUNNEL-MITM]. This attack is referred to as "tunnel 229 MitM attack" in the remainder of this document. The additional 230 protection needed to thwart tunnel MitM attacks depends on the inner 231 method executed within the tunnel. When weak methods are used, these 232 attacks can be mitigated via security policies that require the 233 method to be used only within a tunnel. On the other hand, a 234 technical solution (so-called cryptographic bindings) can be used 235 whenever the inner method derives key material and is not susceptible 236 to attacks outside a tunnel. Only the latter mitigation technique 237 can be made an actual requirement for EAP tunnel methods (see 238 Section 4.6.3), while security policies are outside the scope of this 239 requirement draft. Please refer to the NIST Recommendation for EAP 240 Methods Used in Wireless Network Access Authentication [NIST SP 241 800-120] and [LCN 2010] for a discussion on security policies and 242 complete solutions for thwarting tunnel MitM attacks. 244 The tunnel method MUST support protection of weak EAP methods. 245 Cryptographic protection from tunnel MitM attacks MUST be provided 246 for all key generating methods. In combination with an appropriate 247 security policy this will thwart MitM attacks against inner methods. 249 3.3. Chained EAP Methods 251 Several circumstances are best addressed by using chained EAP 252 methods. For example, it may be desirable to authenticate the user 253 and also authenticate the device being used. However, chained EAP 254 methods from different conversations can be re-directed into the same 255 conversation by an attacker giving the authenticator the impression 256 that both conversations terminate at the same end-point. 257 Cryptographic binding can be used to bind the results of chained key 258 generating methods together or to an encompassing tunnel. 260 The tunnel method MUST support chained EAP methods while including 261 protection against attacks on method chaining. 263 3.4. Identity Protection 265 When performing an EAP authentication, the peer may want to protect 266 its identity and only disclose it to a trusted EAP server. This 267 helps to maintain peer privacy. 269 The tunnel method MUST support identity protection, therefore the 270 identity of the peer used for authentication purposes MUST NOT be 271 obtainable by any entity other than the EAP server terminating the 272 tunnel method. Peer identity protection provided by the tunnel 273 method applies to tunnel method and inner method specific identities. 274 Note that the peer may need to expose the realm portion of the EAP 275 outer identity in the Network Access Identifier (NAI) [RFC4282] in a 276 roaming scenario in order to reach the appropriate authentication 277 server. 279 3.5. Anonymous Service Access 281 When network service is provided, it is sometimes desirable for a 282 user to gain network access in order to access limited services for 283 emergency communication or troubleshooting information. To avoid 284 eavesdropping, it's best to negotiate link layer security as with any 285 other authentication. 287 Therefore, the tunnel method SHOULD allow anonymous peers or server- 288 only authentication, while still deriving keys that can be used for 289 link layer security. The tunnel method MAY also allow for the bypass 290 of server authentication processing on the client. 292 Forgoing user or server authentication increases the chance of man- 293 in-the-middle and other types of attacks that can compromise the 294 derived keys used for link layer security. Therefore, passwords and 295 other sensitive information MUST NOT be disclosed to an 296 unauthenticated server, or to a server that is not authorized to 297 authenticate the user. 299 3.6. Network Endpoint Assessment 301 The Network Endpoint Assessment (NEA) protocols and reference model 302 described in [RFC5209] provide a standard way to check the health 303 ("posture") of a device at or after the time it connects to a 304 network. If the device does not comply with the network's 305 requirements, it can be denied access to the network or granted 306 limited access to remediate itself. EAP is a convenient place for 307 conducting an NEA exchange. 309 The tunnel method SHOULD support carrying NEA protocols such as PB- 310 TNC [RFC5793]. Depending on the specifics of the tunnel method, 311 these protocols may be required to be carried in an EAP method. 313 3.7. Client Authentication During Tunnel Establishment 315 In some cases the peer will have credentials that allow it to 316 authenticate during tunnel establishment. These credentials may only 317 partially authenticate the identity of the peer and additional 318 authentication may be required inside the tunnel. For example, a 319 communication device may be authenticated during tunnel 320 establishment, in addition user authentication may be required to 321 satisfy authentication policy. The tunnel method MUST be capable of 322 providing client side authentication during tunnel establishment. 324 3.8. Extensibility 326 The tunnel method MUST provide extensibility so that additional data 327 related to authentication, authorization and network access can be 328 carried inside the tunnel in the future. This removes the need to 329 develop new tunneling methods for specific purposes. 331 An application for extensibility is credential provisioning. When a 332 peer has authenticated with EAP, this is a convenient time to 333 distribute credentials to that peer that may be used for later 334 authentication exchanges. For example, the authentication server can 335 provide a private key or shared key to the peer that can be used by 336 the peer to perform rapid re-authentication or roaming. In addition 337 there have been proposals to perform enrollment within EAP, such as 338 [I-D.mahy-eap-enrollment]. Another use for extensibility is support 339 for alternate authentication frameworks within the tunnel. 341 3.9. Certificate-less Authentication and Generic EAP Method Extension 343 In some cases the peer will not have a way to verify a server 344 certificate and in some cases a server might not have a certificate 345 to verify. Therefore, it is desirable to support certificate-less 346 authentication. An application for this is credential provisioning 347 where the peer and server authenticate each other with a shared 348 password and credentials for subsequent authentication (e.g. a key 349 pair and certificate or a shared key) can be passed inside the 350 tunnel. Another application is to extend existing EAP methods with 351 new features such as EAP channel bindings. 353 Great care must be taken when using tunnels with no server 354 authentication for the protection of an inner method. For example, 355 the client may lack the appropriate trust roots to fully authenticate 356 the server, but may still establish the tunnel to execute an inner 357 EAP method to perform mutual authentication and key derivation. In 358 these cases, the inner EAP method MUST provide resistance to 359 dictionary attack and a cryptographic binding between the inner 360 method and the tunnel method MUST be established. Furthermore, the 361 cipher suite used to establish the tunnel MUST derive the master key 362 using contribution from both client and server, as in ephemeral 363 Diffie-Hellman cipher suites. 365 The tunnel method MAY allow for certificate-less authentication. 367 4. Requirements 369 4.1. General Requirements 371 4.1.1. RFC Compliance 373 The tunnel method MUST include a Security Claims section with all 374 security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In 375 addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC 376 3748 that tunnel methods MUST support protection against man-in-the- 377 middle attacks. Furthermore, the tunnel method MUST support identity 378 protection as specified in Section 7.3 in RFC 3748. 380 The tunnel method MUST be unconditionally compliant with RFC 4017 381 [RFC4017] (using the definition of "unconditionally compliant" 382 contained in section 1.1 of RFC 4017). This means that the method 383 MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT 384 requirements in RFC 4017. 386 The tunnel method MUST meet all the MUST and SHOULD requirements 387 relevant to EAP methods contained in the EAP Key Management Framework 388 [RFC5247] or any successor. This includes the generation of the MSK, 389 EMSK, Peer-Id, Server-Id and Session-Id. These requirements will 390 enable the tunnel method to properly fit into the EAP key management 391 framework, maintaining all of the security properties and guarantees 392 of that framework. 394 The tunnel method MUST NOT be tied to any single cryptographic 395 algorithm. Instead, it MUST support run-time negotiation to select 396 among an extensible set of cryptographic algorithms, such as 397 algorithms used with certificates presented during tunnel 398 establishment. This "cryptographic algorithm agility" provides 399 several advantages. Most important, when a weakness in an algorithm 400 is discovered or increased processing power overtakes an algorithm, 401 users can easily transition to a new algorithm. Also, users can 402 choose the algorithm that best meets their needs. 404 The tunnel method MUST meet the SHOULD and MUST requirements 405 pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. 406 This includes: cryptographic algorithm independence; strong, fresh 407 session keys; replay detection; keying material confidentiality and 408 integrity; and confirmation of cipher suite selection. 410 4.2. Tunnel Requirements 412 The following section discusses requirements for TLS Tunnel 413 Establishment. 415 4.2.1. TLS Requirements 417 The tunnel based method MUST support TLS version 1.2 [RFC5246] and 418 may support earlier versions greater than SSL 2.0 to enable the 419 possibility of backwards compatibility. 421 4.2.1.1. Cipher Suites 423 4.2.1.1.1. Cipher Suite Negotiation 425 Cipher suite negotiations always suffer from downgrading attacks when 426 they are not secured by any kind of integrity protection. A common 427 practice is a post integrity check in which, as soon as available, 428 the established keys (here the tunnel key) are used to derive 429 integrity keys. These integrity keys are then used by peer and 430 authentication server to verify whether the cipher suite negotiation 431 has been maliciously altered by another party. 433 Integrity checks prevent downgrading attacks only if the derived 434 integrity keys and the employed integrity algorithms cannot be broken 435 in real-time. See Section 6.1 or [KHLC07] for more information on 436 this. Hence, the tunnel method MUST provide integrity protected 437 cipher suite negotiation with secure integrity algorithms and 438 integrity keys. 440 TLS provides protected cipher suite negotiation as long as all the 441 cipher suites supported provide authentication, key establishment and 442 data integrity protection as discussed in Section 6.1. 444 4.2.1.1.2. Tunnel Data Protection Algorithms 446 In order to prevent attacks on the cryptographic algorithms employed 447 by inner authentication methods, a tunnel protocol's protection needs 448 to provide a basic level of algorithm strength. The tunnel method 449 MUST provide at least one mandatory to implement cipher suite that 450 provides the equivalent security of 128-bit AES for encryption and 451 message authentication. See Part 1 of the NIST Recommendation for 452 Key Management [NIST SP 800-57] for a discussion of the relative 453 strengths of common algorithms. 455 4.2.1.1.3. Tunnel Authentication and Key Establishment 457 A tunnel method MUST provide unidirectional authentication from 458 authentication server to EAP peer and mutual authentication between 459 authentication server and EAP peer. The tunnel method MUST provide 460 at least one mandatory to implement cipher suite that provides 461 certificate-based authentication of the server and provides optional 462 certificate-based authentication of the client. Other types of 463 authentication MAY be supported. 465 At least one mandatory to implement cipher suite MUST be approved by 466 NIST Draft Recommendation for Key Management, Part 3 [NIST SP 467 800-57p3], i.e., the ciphersuite MUST be listed in Table 4-1, 4-2 or 468 4-3 in that document. 470 The mandatory to implement cipher suites MUST only include cipher 471 suites that use strong cryptographic algorithms. They MUST NOT 472 include cipher suites providing mutually anonymous authentication or 473 static Diffie-Hellman cipher suites. 475 Other ciphersuites MAY be selected following the security 476 requirements for tunnel protocols in NIST DRAFT Recommendation for 477 EAP Methods Used in Wireless Network Access Authentication [NIST SP 478 800-120]. 480 4.2.1.2. Tunnel Replay Protection 482 In order to prevent replay attacks on a tunnel protocol, the message 483 authentication MUST be generated using a time-variant input such as 484 timestamps, sequence numbers, nonces, or a combination of these so 485 that any re-use of the authentication data can be detected as 486 invalid. TLS provides sufficient replay protection to meet this 487 requirements as long as weak cipher suites discussed in Section 6.1 488 are avoided. 490 4.2.1.3. TLS Extensions 492 In order to meet the requirements in this document TLS extensions MAY 493 be used. For example, TLS extensions may be useful in providing 494 certificate revocation information via the TLS Online Certificate 495 Status Protocol (OCSP) extension [I-D.ietf-tls-rfc4366-bis] (thus 496 meeting the requirement in Section 4.5.1.3). 498 4.2.1.4. Peer Identity Privacy 500 A tunnel protocol MUST support peer privacy. This requires that the 501 username and other attributes associated with the peer are not 502 transmitted in the clear or to an unauthenticated, unauthorized 503 party. Peer identity protection provided by the tunnel method 504 applies to establishment of the tunnel and protection of inner method 505 specific identities. If applicable, the peer certificate is sent 506 confidentially (i.e. encrypted). 508 4.2.1.5. Session Resumption 510 The tunnel method MUST support TLS session resumption as defined in 511 [RFC5246]. The tunnel method MAY support other methods of session 512 resumption such as those defined in [RFC5077]. 514 4.2.2. Fragmentation 516 Tunnel establishment sometimes requires the exchange of information 517 that exceeds what can be carried in a single EAP message. In 518 addition information carried within the tunnel may also exceed this 519 limit. Therefore a tunnel method MUST support fragmentation and 520 reassembly. 522 4.2.3. Protection of Data External to Tunnel 524 A man-in-the-middle attacker can modify clear text values such as 525 protocol version and type code information communicated outside the 526 TLS tunnel. The tunnel method MUST provide implicit or explicit 527 protection of the protocol version and type code. If modification of 528 other information external to the tunnel can cause exploitable 529 vulnerabilities, the tunnel method MUST provide protection against 530 modification of this additional data. 532 4.3. Tunnel Payload Requirements 534 This section describes the payload requirements inside the tunnel. 535 These requirements frequently express features that a candidate 536 protocol must be capable of offering so that a deployer can decide 537 whether to make use of that feature. This section does not state 538 requirements about what features of each protocol must be used during 539 a deployment. 541 4.3.1. Extensible Attribute Types 543 The payload MUST be extensible. Some standard payload attribute 544 types will be defined to meet known requirements listed below, such 545 as password authentication, inner EAP method, vendor specific 546 attributes, and result indication. Additional payload attributes MAY 547 be defined in the future to support additional features and data 548 types. 550 4.3.2. Request/Challenge Response Operation 552 The payload MUST support request and response type of half-duplex 553 operation typical of EAP. Multiple attributes may be sent in a 554 single payload. The payload MAY support carrying on multiple 555 authentications in a single payload packet. 557 4.3.3. Indicating Criticality of Attributes 559 It is expected that new attributes will be defined to be carried 560 within the tunnel method. In some cases it is necessary for the 561 sender to know if the receiver did not understand the attribute. To 562 support this, there MUST be a way for the sender to mark attributes 563 such that the receiver will indicate if an attribute is not 564 understood. 566 4.3.4. Vendor Specific Support 568 The payload MUST support communication of an extensible set of 569 vendor-specific attributes. These attributes will be segmented into 570 uniquely identified vendor specific name spaces. They can be used 571 for experiments or vendor specific features. 573 4.3.5. Result Indication 575 The payload MUST support result indication and its acknowledgement, 576 so both the EAP peer and server will end up with a synchronized 577 state. The result indication is needed after each chained inner 578 authentication method and at the end of the authentication, so 579 separate result indication for intermediate and final result MUST be 580 supported. 582 4.3.6. Internationalization of Display Strings 584 The payload MAY provide a standard attribute format that supports 585 international strings. This attribute format MUST support encoding 586 strings in UTF-8 [RFC3629] format. Any strings sent by the server 587 intended for display to the user MUST be sent in UTF-8 format and 588 SHOULD be able to be marked with language information and adapted to 589 the user's language preference as indicated by RFC 5646 [RFC5646]. 590 Note that in some cases, such as when transmitting error codes, it is 591 acceptable to exchange numeric codes that can be translated by the 592 client to support the particular local language. These numeric codes 593 are not subject internationalization during transmission. 595 4.4. EAP Channel Binding Requirements 597 The tunnel method MUST be capable of meeting EAP channel binding 598 requirements described in [I-D.ietf-emu-chbind]. As discussed in 599 [RFC5056], EAP Channel bindings differ from channel bindings 600 discussed in other contexts. Cryptographic binding between the TLS 601 tunnel and the inner method discussed in Section 4.6.3 relates 602 directly to the non-EAP channel binding concepts discussed in RFC 603 5056. 605 4.5. Requirements Associated with Carrying Username and Passwords 607 This section describes the requirements associated with tunneled 608 password authentication. The password authentication mentioned here 609 refers to user or machine authentication using a legacy password 610 database or verifier, such as LDAP [RFC4511], OTP, etc. These 611 typically require the password in its original text form in order to 612 authenticate the peer, hence they require the peer to send the clear 613 text user name and password to the EAP server. 615 4.5.1. Security 617 Many internal EAP methods have the peer send its password in the 618 clear to the EAP server. Other methods (e.g. challenge-response 619 methods) are vulnerable to attacks if an eavesdropper can intercept 620 the traffic. For any such methods, the security measures in the 621 following sections MUST be met. 623 4.5.1.1. Confidentiality and Integrity 625 The clear text password exchange MUST be integrity and 626 confidentiality protected. As long as the password exchange occurs 627 inside an authenticated and encrypted tunnel, this requirement is 628 met. 630 4.5.1.2. Authentication of Server 632 The EAP server MUST be authenticated before the peer sends the clear 633 text password to the server. 635 4.5.1.3. Server Certificate Revocation Checking 637 When certificate authentication is used during tunnel establishment 638 the EAP peer may need to present its password to the server before it 639 has network access to check the revocation status of the server's 640 credentials. Therefore, the tunnel method MUST support mechanisms to 641 check the revocation status of a credential. The tunnel method 642 SHOULD make use of Online Certificate Status Protocol (OCSP) 643 [RFC2560] or Server-based Certificate Validation Protocol (SCVP) 644 [RFC5055] to obtain the revocation status of the EAP server 645 certificate. 647 4.5.2. Internationalization 649 The password authentication exchange MUST support user names and 650 passwords in international languages. It MUST support encoding of 651 user name and password strings in UTF-8 [RFC3629] format. The method 652 MUST specify how username and password normalizations and/or 653 comparisons is performed in reference to SASLPrep [RFC4013], 654 Net-UTF-8 [RFC5198] or their replacement. 656 Any strings sent by the server intended for display to the user MUST 657 be sent in UTF-8 format and SHOULD be able to be marked with language 658 information and adapted to the user's language preference as 659 indicated by RFC 5646 [RFC5646]. Note that in some cases, such as 660 when transmitting error codes, it is acceptable to exchange numeric 661 codes that can be translated by the client to support the particular 662 local language. These numeric codes are not subject to 663 internationalization during transmission. 665 4.5.3. Meta-data 667 The password authentication exchange SHOULD support additional 668 associated meta-data which can be used to indicate whether the 669 authentication is for a user or a machine. This allows the EAP 670 server and peer to request and negotiate authentication specifically 671 for a user or machine. This is useful in the case of multiple inner 672 authentications where the user and machine both need to be 673 authenticated. 675 4.5.4. Password Change 677 The password authentication exchange MUST support password change. 678 The exchange SHOULD be extensible to support other "housekeeping" 679 functions, such as the management of PINs or other data, required by 680 some systems. 682 4.6. Requirements Associated with Carrying EAP Methods 684 The tunnel method MUST be able to carry inner EAP methods without 685 modifying them. EAP methods MUST NOT be redefined inside the tunnel. 687 4.6.1. Method Negotiation 689 The tunnel method MUST support the protected negotiation of the inner 690 EAP method. It MUST NOT allow the inner EAP method negotiation to be 691 manipulated by intermediaries. 693 4.6.2. Chained Methods 695 The tunnel method SHOULD support the chaining of multiple EAP 696 methods. The tunnel method MUST allow for the communication of 697 intermediate result and verification of compound binding between 698 executed inner methods when chained methods are employed. 700 4.6.3. Cryptographic Binding with the TLS Tunnel 702 The tunnel method MUST provide a mechanism to bind the tunnel 703 protocol and the inner EAP method. This property is referred to as 704 cryptographic binding. Such bindings are an important tool for 705 mitigating the tunnel MitM attacks on tunnel methods [TUNNEL-MITM]. 706 Cryptographic bindings enable the complete prevention of tunnel MitM 707 attacks without the need of additional security policies as long as 708 the inner method derives keys and is not vulnerable to attacks 709 outside a protected tunnel [LCN 2010]. Even though weak or non-key 710 deriving inner methods may be permitted, and thus security policies 711 preventing tunnel MitM attacks are still necessary, the tunnel method 712 MUST provide cryptographic bindings, because only this allows 713 migrating to more secure, policy-independent implementations. 715 Cryptographic bindings are typically achieved by securely mixing the 716 established keying material (say tunnel key TK) from the tunnel 717 protocol with the established keying material (say method key MK) 718 from the inner authentication method(s) in order to derive fresh 719 keying material. If chained EAP methods are executed in the tunnel, 720 all derived inner keys are combined with the tunnel key to create a 721 new compound tunnel key (CTK). In particular, CTK is used to derive 722 the EAP MSK, EMSK and other transient keys (TEK), such as transient 723 encryption keys and integrity protection keys. The key hierarchy for 724 tunnel methods executions that derive compound keys for the purpose 725 of cryptographic binding is depicted in Figure 1. 727 In the case of the sequential executions of n inner methods, a 728 chained compound key CTK_i MUST be computed upon the completion of 729 each inner method i such that it contains the compound key of all 730 previous inner methods, i.e. CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n 731 and CTK_0=TK, where f() is a key derivation function, such as one 732 that complies with NIST Recommendation for Key Derivation Using 733 Pseudorandom Functions [NIST SP 800-108]. CTK_n SHOULD serve as the 734 key to derive further keys. Figure 1 depicts the key hierarchy in 735 the case of a single inner method. Transient keys derived from the 736 compound key CTK are used in a cryptographic protocol to verify the 737 integrity of the tunnel and the inner authentication method. 739 ----------- 740 | TK | MK | 741 ----------- 742 | | 743 v v 744 -------- 745 | CTK | 746 -------- 747 | 748 v 749 ---------------- 750 | | | 751 v v v 752 ------- ------ ------- 753 | TEK | | MSK | | EMSK | 754 ------- ------- -------- 756 Figure 1: Compound Keys 758 Furthermore, all compound keys CTK_i and all keys derived from it 759 SHOULD follow the recommendations for key derivations and key 760 hierarchies as specified in [NIST SP 800-108]. In particular, all 761 derived keys MUST have a lifetime assigned that does not exceed the 762 lifetime of any key higher in the key hierarchy. The derivation MUST 763 prevent a compromise in one part of the system from leading to 764 compromises in other parts of the system that relay on keys at the 765 same or higher level in the hierarchy. 767 4.6.4. Peer Initiated 769 The tunnel method SHOULD allow for the peer to initiate an inner EAP 770 authentication in order to meet its policy requirements for 771 authenticating the server. 773 4.6.5. Method Meta-data 775 The tunnel method SHOULD allow for the communication of additional 776 data associated with an EAP method. This can be used to indicate 777 whether the authentication is for a user or a machine. This allows 778 the EAP server and peer to request and negotiate authentication 779 specifically for a user or machine. This is useful in the case of 780 multiple inner EAP authentications where the user and machine both 781 need to be authenticated. 783 5. IANA Considerations 785 This document has no IANA considerations. 787 6. Security Considerations 789 A tunnel method is often deployed to provide mutual authentication 790 between EAP Peer and EAP Server and to generate key material for use 791 in protecting lower layer protocols. In addition the tunnel is used 792 to protect the communication of additional data, including peer 793 identity between the EAP Peer and EAP Server from disclosure to or 794 modification by an attacker. These sections cover considerations 795 that affect the ability for a method to achieve these goals. 797 6.1. Cipher Suite Selection 799 TLS supports a wide variety of cipher suites providing a variety of 800 security properties. The selection of cipher suites is critical to 801 the security of the tunnel method. Selection of a cipher suite with 802 weak or no authentication, such as an anonymous Diffie- Hellman based 803 cipher suite will greatly increase the risk of system compromise. 804 Since a tunnel method uses the TLS tunnel to transport data, the 805 selection of a ciphersuite with weak data encryption and integrity 806 algorithms will also increase the vulnerability of the method to 807 attacks. 809 A tunnel protocol is prone to downgrading attacks if the tunnel 810 protocol supports any key establishment algorithm that can be broken 811 on-line. In a successful downgrading attack, an adversary breaks the 812 selected "weak" key establishment algorithm and optionally the "weak" 813 authentication algorithm without being detected. Here, "weak" refers 814 to a key establishment algorithm that can be broken in real-time, and 815 an authentication scheme that can be broken off-line, respectively. 816 See [KHLC07] for more details. The requirements in this document 817 disapprove the use of key establishment algorithms that can be broken 818 on-line. 820 Mutually anonymous tunnel protocols are prone to man-in-the-middle 821 attacks described in [KHLC07]. During such an attack, an adversary 822 establishes a tunnel with each the peer and the authentication 823 server, while peer and server believe that they established a tunnel 824 with each other. Once both tunnels have been established, the 825 adversary can eavesdrop on all communications within the tunnels, 826 i.e. the execution of the inner authentication method(s). 827 Consequently, the adversary can eavesdrop on the identifiers that are 828 exchanged as part of the EAP method and thus, the privacy of peer 829 and/or authentication server is compromised along with any other data 830 transmitted within the tunnels. This document requires server 831 authentication to avoid the risks associated with anonymous cipher 832 suites. 834 6.2. Tunneled Authentication 836 In many cases a tunnel method provides mutual authentication by 837 authenticating the server during tunnel establishment and 838 authenticating the peer within the tunnel using an EAP method. As 839 described in [TUNNEL-MITM], this mode of operation can allow tunnel 840 man-in-the-middle attackers to authenticate to the server as the peer 841 by tunneling the inner EAP protocol messages to and from a peer 842 executing the method outside a tunnel or with an untrustworthy 843 server. Cryptographic binding between the established keying 844 material from the inner authentication method(s) and the tunnel 845 protocol verifies that the endpoints of the tunnel and the inner 846 authentication method(s) are the same. This can thwart the attack if 847 the inner method derived keys of sufficient strength that they cannot 848 be broken in real-time. 850 In cases where the inner authentication method does not generate any 851 or only weak key material, security policies MUST be enforced such 852 that the peer cannot execute the inner method with the same 853 credentials outside a protective tunnel or with an untrustworthy 854 server. 856 6.3. Data External to Tunnel 858 The tunnel method will use data that is outside the TLS tunnel such 859 as the EAP type code or version numbers. If an attacker can 860 compromise the protocol by modifying these values the tunnel method 861 MUST protect this data from modification. In some cases external 862 data may not need additional protection because it is implicitly 863 verified during the protocol operation. 865 6.4. Separation of TLS Tunnel and Inner Authentication Termination 867 Terminating the inner method at a different location than the outer 868 tunnel needs careful consideration. The inner method data may be 869 vulnerable to modification and eavesdropping between the server that 870 terminates the tunnel and the server that terminates the inner 871 method. For example if a clear text password is used then it may be 872 sent to the inner method server in a RADIUS password attribute which 873 uses weak encryption that may not be suitable protection for many 874 environments. 876 In some cases terminating the tunnel at a different location may make 877 it difficult for a peer to authenticate the server and trust it for 878 further communication. For example, if the TLS tunnel is terminated 879 by a different organization the peer needs to be able to authenticate 880 and authorize the tunnel server to handle secret credentials that it 881 shares with the home server that terminates the inner method. This 882 may not meet the security policy of many environments. 884 7. References 886 7.1. Normative References 888 [I-D.ietf-emu-chbind] 889 Hartman, S., Clancy, C., and K. Hoeper, "Channel Binding 890 Support for EAP Methods", draft-ietf-emu-chbind-06 (work 891 in progress), October 2010. 893 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 894 Adams, "X.509 Internet Public Key Infrastructure Online 895 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 897 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 898 10646", STD 63, RFC 3629, November 2003. 900 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 901 Levkowetz, "Extensible Authentication Protocol (EAP)", 902 RFC 3748, June 2004. 904 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 905 Authentication Protocol (EAP) Method Requirements for 906 Wireless LANs", RFC 4017, March 2005. 908 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 909 Authorization, and Accounting (AAA) Key Management", 910 BCP 132, RFC 4962, July 2007. 912 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 913 Polk, "Server-Based Certificate Validation Protocol 914 (SCVP)", RFC 5055, December 2007. 916 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 917 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 919 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 920 Authentication Protocol (EAP) Key Management Framework", 921 RFC 5247, August 2008. 923 7.2. Informative References 925 [I-D.ietf-tls-rfc4366-bis] 926 3rd, D., "Transport Layer Security (TLS) Extensions: 927 Extension Definitions", draft-ietf-tls-rfc4366-bis-12 928 (work in progress), September 2010. 930 [I-D.mahy-eap-enrollment] 931 Mahy, R., "An Extensible Authentication Protocol (EAP) 932 Enrollment Method", draft-mahy-eap-enrollment-01 (work in 933 progress), March 2006. 935 [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", 936 ICST QShine , August 2007. 938 [LCN 2010] 939 Hoeper, K. and L. Chen, "An Inconvenient Truth about 940 Tunneled Authentications", Proceedings of 35th Annual IEEE 941 Conference on Local Computer Networks (LCN 2010) , 942 September 2009. 944 [NIST SP 800-108] 945 Chen, L., "Recommendation for Key Derivation Using 946 Pseudorandom Functions", Draft NIST Special 947 Publication 800-108, April 2008. 949 [NIST SP 800-120] 950 Hoeper, K. and L. Chen, "Recommendation for EAP Methods 951 Used in Wireless Network Access Authentication", NIST 952 Special Publication 800-120, September 2009. 954 [NIST SP 800-57] 955 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, 956 "Recommendation for Key Management - Part 1: General 957 (Revised)", NIST Special Publication 800-57, part 1, 958 March 2007. 960 [NIST SP 800-57p3] 961 Barker, E., Burr, W., Jones, A., Polk, W., , S., and M. 962 Smid, "Recommendation for Key Management, Part 3 963 Application-Specific Key Management Guidance", Draft NIST 964 Special Publication 800-57,part 3, October 2008. 966 [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible 967 Authentication Protocol (PEAP) Specification", 968 August 2009. 970 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 971 and Passwords", RFC 4013, February 2005. 973 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 974 Network Access Identifier", RFC 4282, December 2005. 976 [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol 977 (LDAP): The Protocol", RFC 4511, June 2006. 979 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 980 Flexible Authentication via Secure Tunneling Extensible 981 Authentication Protocol Method (EAP-FAST)", RFC 4851, 982 May 2007. 984 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 985 Channels", RFC 5056, November 2007. 987 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 988 "Transport Layer Security (TLS) Session Resumption without 989 Server-Side State", RFC 5077, January 2008. 991 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 992 Interchange", RFC 5198, March 2008. 994 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 995 Tardo, "Network Endpoint Assessment (NEA): Overview and 996 Requirements", RFC 5209, June 2008. 998 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 999 Protocol Tunneled Transport Layer Security Authenticated 1000 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 1002 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1003 Languages", BCP 47, RFC 5646, September 2009. 1005 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 1006 A Posture Broker (PB) Protocol Compatible with Trusted 1007 Network Connect (TNC)", RFC 5793, March 2010. 1009 [TUNNEL-MITM] 1010 Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 1011 in Tunnelled Authentication Protocols", Cryptology ePrint 1012 Archive: Report 2002/163, November 2002. 1014 Appendix A. Changes from -01 1015 o Added combined mutual authentication in section 3.1 1016 o Changed reference from SP 800-52 to SP 800-57,part 3 1017 o In section 6.2 changed terminology to tunnel MitM and security 1018 policy enforcement 1019 o Reworded text in section 3.2 to clarify MITM protection 1020 o Added more specific text about derivation of the CTK 1021 o Removed resource constrained section 1022 o Added support for Non EAP authentication as a use for 1023 extensibility 1024 o Added text to emergency services section to emphasize that 1025 sensitive information should not be sent if the server is 1026 unauthenticated. 1027 o Reworded TLS requirements 1028 o Reworded external data protection requirements 1029 o Added text to section 4.6 that states method must not be re- 1030 defined inside the tunnel. 1031 o Editorial fixes 1033 Appendix B. Changes from -02 1034 o Editorial Fixes 1035 o Clarified client authentication during tunnel establishment 1036 o Changed text so that the tunnel method MUST meet all MUST and 1037 SHOULD requirements relevant to EAP methods in RFCs 4962 and 5247 1039 Appendix C. changes from -03 1040 o Resolution of open issues: 1041 http://trac.tools.ietf.org/wg/emu/trac/report/9 1043 o Revised section 2 to match other similar RFC(Issue 6) 1044 o Cleaned up section 3.2 (issue 8) 1045 o Clarified identity protection scope in section 3.4 and 1046 4.2.1.4(issue 9) 1047 o Changed Emergency Services to anonymous authentication(section 1048 3.5)(issue 10) 1049 o Clarified section 4.1.1 (issue 15) 1050 o Cleaned up TLS requirements in section 4.2.1(issue 11) 1051 o Replaced text in 4.2.1.1.3 with suitable reference 1052 o Improved wording in 4.2.3 and 6.3 (issue 13) 1053 o Update internationalization requirements in 4.3.6 and 4.5.2 1054 (Issues 25,18) 1055 o Updated text in 4.5.1 (issue 16) 1056 o Changed meta-data to SHOULD in 4.5.3 and 4.6.5(Issue 20) 1057 o Changed chained methods to SHOULD in 4.6.2(issue 19) 1058 o Added security consideration for inner method termination(issue 1059 24) 1060 o Updated references 1061 o Editorial changes(issues 7,22,17) 1063 Authors' Addresses 1065 Katrin Hoeper 1066 Motorola, Inc. 1067 1301 E Algonquin Rd 1068 Schaumburg, IL 60196 1069 USA 1071 Email: khoeper@motorola.com 1073 Stephen Hanna 1074 Juniper Networks 1075 3 Beverly Road 1076 Bedford, MA 01730 1077 USA 1079 Email: shanna@juniper.net 1080 Hao Zhou 1081 Cisco Systems, Inc. 1082 4125 Highlander Parkway 1083 Richfield, OH 44286 1084 USA 1086 Email: hzhou@cisco.com 1088 Joseph Salowey (editor) 1089 Cisco Systems, Inc. 1090 2901 3rd. Ave 1091 Seattle, WA 98121 1092 USA 1094 Email: jsalowey@cisco.com