summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6678.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6678.txt')
-rw-r--r--doc/rfc/rfc6678.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc6678.txt b/doc/rfc/rfc6678.txt
new file mode 100644
index 0000000..9ec7c5a
--- /dev/null
+++ b/doc/rfc/rfc6678.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Hoeper
+Request for Comments: 6678 Motorola Solutions, Inc.
+Category: Informational S. Hanna
+ISSN: 2070-1721 Juniper Networks
+ H. Zhou
+ J. Salowey, Ed.
+ Cisco Systems, Inc.
+ July 2012
+
+
+ Requirements for a
+ Tunnel-Based Extensible Authentication Protocol (EAP) Method
+
+Abstract
+
+ This memo defines the requirements for a tunnel-based Extensible
+ Authentication Protocol (EAP) Method. This tunnel method will use
+ Transport Layer Security (TLS) to establish a secure tunnel. The
+ tunnel will provide support for password authentication, EAP
+ authentication, and the transport of additional data for other
+ purposes.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6678.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+
+
+
+Hoeper, et al. Informational [Page 1]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
+ 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Password Authentication . . . . . . . . . . . . . . . . . 5
+ 3.2. Protection of Weak EAP Methods . . . . . . . . . . . . . . 5
+ 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 6
+ 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6
+ 3.5. Anonymous Service Access . . . . . . . . . . . . . . . . . 7
+ 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 7
+ 3.7. Client Authentication during Tunnel Establishment . . . . 7
+ 3.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.9. Certificate-Less Authentication and Generic EAP Method
+ Extension . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 9
+ 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 9
+ 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 10
+ 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 10
+ 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 10
+ 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 10
+ 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10
+ 4.2.1.1.3. Tunnel Authentication and Key Establishment . 11
+ 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11
+ 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11
+ 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 11
+ 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12
+ 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
+ 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12
+ 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12
+
+
+
+Hoeper, et al. Informational [Page 2]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+ 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12
+ 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13
+ 4.3.3. Indicating Criticality of Attributes . . . . . . . . . 13
+ 4.3.4. Vendor-Specific Support . . . . . . . . . . . . . . . 13
+ 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13
+ 4.3.6. Internationalization of Display Strings . . . . . . . 13
+ 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14
+ 4.5. Requirements Associated with Carrying Username and
+ Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14
+ 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14
+ 4.5.1.3. Server Certificate Revocation Checking . . . . . . 14
+ 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
+ 4.5.3. Metadata . . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15
+ 4.6. Requirements Associated with Carrying EAP Methods . . . . 15
+ 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16
+ 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16
+ 4.6.3. Cryptographic Binding with the TLS Tunnel . . . . . . 16
+ 4.6.4. Peer-Initiated EAP Authentication . . . . . . . . . . 17
+ 4.6.5. Method Metadata . . . . . . . . . . . . . . . . . . . 17
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 5.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 18
+ 5.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19
+ 5.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19
+ 5.4. Separation of TLS Tunnel and Inner Authentication
+ Termination . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
+ 6.2. Informative References . . . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 3]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+1. Introduction
+
+ An Extensible Authentication Protocol (EAP) tunnel method is an EAP
+ method that establishes a secure tunnel and executes other EAP
+ methods under the protection of that secure tunnel. An EAP tunnel
+ method can be used in any lower-layer protocol that supports EAP
+ authentication. There are several existing EAP tunnel methods that
+ use Transport Layer Security (TLS) to establish the secure tunnel.
+ EAP methods supporting this include Protected EAP [PEAP], Tunneled
+ Transport Layer Security EAP (TTLS) [RFC5281] and EAP Flexible
+ Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. In
+ general, this has worked well so there is consensus to continue to
+ use TLS as the basis for a tunnel method. There have been various
+ reasons for employing a protected tunnel for EAP processes. They
+ include protecting weak authentication exchanges, such as username
+ and password. In addition, a protected tunnel can provide means to
+ provide peer identity protection and EAP method chaining. Finally,
+ systems have found it useful to transport additional types of data
+ within the protected tunnel.
+
+ This document describes the requirements for a EAP tunnel method as
+ well as for a password protocol supporting legacy password
+ verification within the tunnel method.
+
+2. Conventions Used in This Document
+
+ Use of each capitalized word within a sentence or phrase carries the
+ following meaning during the EAP Method Update (EMU) WG's method
+ selection process:
+
+ MUST - indicates an absolute requirement
+
+ MUST NOT - indicates something absolutely prohibited
+
+ SHOULD - indicates a strong recommendation of a desired result
+
+ SHOULD NOT - indicates a strong recommendation against a result
+
+ MAY - indicates a willingness to allow an optional outcome
+
+ Lowercase uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and
+ "MAY" carry their normal meaning and are not subject to these
+ definitions.
+
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 4]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+3. Use Cases
+
+ To motivate and explain the requirements in this document, a
+ representative set of use cases for the EAP tunnel method are
+ supplied here. It is mandatory for a candidate tunnel method to
+ support all of the use cases that are marked below as "MUST".
+
+3.1. Password Authentication
+
+ Many legacy systems only support user authentication with passwords.
+ Some of these systems require transport of the actual username and
+ password to the authentication server. This is true for systems
+ where the authentication server does not have access to the cleartext
+ password or a consistent transform of the cleartext password.
+ Examples of such systems are some one-time password (OTP) systems and
+ other systems where the username and password are submitted to an
+ external party for validation. The tunnel method MUST support
+ transporting cleartext username and password to the EAP server. It
+ MUST NOT reveal information about the username and password to
+ parties in the communication path between the peer and the EAP
+ server. The advantage any attacker gains against the tunnel method
+ when employing a username and password for authentication MUST be
+ through interaction and not computation. The tunnel MUST support
+ protection from man-in-the-middle attacks. The combination of the
+ tunnel authentication and password authentication MUST enable mutual
+ authentication.
+
+ Since EAP authentication occurs before network access is granted the
+ tunnel method SHOULD enable an inner exchange to provide support for
+ minimal password management tasks including password change, "new PIN
+ mode", and "next token mode" required by some systems.
+
+3.2. Protection of Weak EAP Methods
+
+ Some existing EAP methods have vulnerabilities that could be
+ eliminated or reduced by running them inside a protected tunnel. For
+ example, an EAP-MD5 method does not provide mutual authentication or
+ protection from dictionary attacks. Without extra protection, EAP
+ tunnel methods are vulnerable to a special type of tunnel man-in-the-
+ middle (MitM) attack [TUNNEL-MITM]. This attack is referred to as
+ "tunnel MitM attack" in the remainder of this document. The
+ additional protection needed to thwart tunnel MitM attacks depends on
+ the inner method executed within the tunnel. When weak methods are
+ used, these attacks can be mitigated via security policies that
+ require the method to be used only within a tunnel. On the other
+ hand, a technical solution (so-called cryptographic bindings) can be
+ used whenever the inner method derives key material and is not
+ susceptible to attacks outside a tunnel. Only the latter mitigation
+
+
+
+Hoeper, et al. Informational [Page 5]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+ technique can be made an actual requirement for EAP tunnel methods
+ (see Section 4.6.3), while security policies are outside the scope of
+ this requirement document. Please refer to the NIST "Recommendation
+ for EAP Methods Used in Wireless Network Access Authentication"
+ [NIST-SP-800-120] and [LCN-2010] for a discussion on security
+ policies and complete solutions for thwarting tunnel MitM attacks.
+
+ The tunnel method MUST support protection of weak EAP methods.
+ Cryptographic protection from tunnel MitM attacks MUST be provided
+ for all key-generating methods. In combination with an appropriate
+ security policy this will thwart MitM attacks against inner methods.
+
+3.3. Chained EAP Methods
+
+ Several circumstances are best addressed by using chained EAP
+ methods. For example, it may be desirable to authenticate the user
+ and also authenticate the device being used. However, chained EAP
+ methods from different conversations can be redirected into the same
+ conversation by an attacker giving the authenticator the impression
+ that both conversations terminate at the same endpoint.
+ Cryptographic binding can be used to bind the results of chained key-
+ generating methods together or to an encompassing tunnel.
+
+ The tunnel method MUST support chained EAP methods while including
+ protection against attacks on method chaining.
+
+3.4. Identity Protection
+
+ When performing an EAP authentication, the peer may want to protect
+ its identity and only disclose it to a trusted EAP server. This
+ helps to maintain peer privacy.
+
+ The tunnel method MUST support identity protection, therefore the
+ identity of the peer used for authentication purposes MUST NOT be
+ obtainable by any entity other than the EAP server terminating the
+ tunnel method. Peer identity protection provided by the tunnel
+ method applies to the identities that are specific to the tunnel
+ method and inner method being used. In a roaming scenario, note that
+ the peer may need to expose the realm portion of the EAP outer
+ identity in the Network Access Identifier (NAI) [RFC4282] in order to
+ reach the appropriate authentication server.
+
+
+
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 6]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+3.5. Anonymous Service Access
+
+ When network service is provided, it is sometimes desirable for a
+ user to gain network access in order to access limited services for
+ emergency communication or troubleshooting information. To avoid
+ eavesdropping, it's best to negotiate link-layer security as with any
+ other authentication.
+
+ Therefore, the tunnel method SHOULD allow anonymous peers or server-
+ only authentication, while still deriving keys that can be used for
+ link-layer security. The tunnel method MAY also allow for the bypass
+ of server authentication processing on the client.
+
+ Foregoing user or server authentication increases the chance of man-
+ in-the-middle and other types of attacks that can compromise the
+ derived keys used for link-layer security. Therefore, passwords and
+ other sensitive information MUST NOT be disclosed to an
+ unauthenticated server, or to a server that is not authorized to
+ authenticate the user.
+
+3.6. Network Endpoint Assessment
+
+ The Network Endpoint Assessment (NEA) protocols and reference model
+ described in [RFC5209] provide a standard way to check the health
+ ("posture") of a device at or after the time it connects to a
+ network. If the device does not comply with the network's
+ requirements, it can be denied access to the network or granted
+ limited access to remediate itself. EAP is a convenient place for
+ conducting an NEA exchange.
+
+ The tunnel method SHOULD support carrying NEA protocols such as a
+ Posture Broker protocol compatible with Trusted Network Connect
+ (PB-TNC) [RFC5793]. Depending on the specifics of the tunnel method,
+ these protocols may be required to be carried in an EAP method.
+
+3.7. Client Authentication during Tunnel Establishment
+
+ In some cases, the peer will have credentials that allow it to
+ authenticate during tunnel establishment. These credentials may only
+ partially authenticate the identity of the peer and additional
+ authentication may be required inside the tunnel. For example, a
+ communication device may be authenticated during tunnel
+ establishment; in addition, user authentication may be required to
+ satisfy authentication policy. The tunnel method MUST be capable of
+ providing client-side authentication during tunnel establishment.
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 7]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+3.8. Extensibility
+
+ The tunnel method MUST provide extensibility so that additional data
+ related to authentication, authorization, and network access can be
+ carried inside the tunnel in the future. This removes the need to
+ develop new tunneling methods for specific purposes.
+
+ An application for extensibility is credential provisioning. When a
+ peer has authenticated with EAP, this is a convenient time to
+ distribute credentials to that peer that may be used for later
+ authentication exchanges. For example, the authentication server can
+ provide a private key or shared key to the peer that can be used by
+ the peer to perform rapid re-authentication or roaming. In addition,
+ there have been proposals to perform enrollment within EAP, such as
+ [EAP-ENROLL]. Another use for extensibility is support for alternate
+ authentication frameworks within the tunnel.
+
+3.9. Certificate-Less Authentication and Generic EAP Method Extension
+
+ In some cases, the peer will not have a way to verify a server
+ certificate and, in some cases, a server might not have a certificate
+ to verify. Therefore, it is desirable to support certificate-less
+ authentication. An application for this is credential provisioning
+ where the peer and server authenticate each other with a shared
+ password and credentials for subsequent authentication (e.g., a key
+ pair and certificate, or a shared key) can be passed inside the
+ tunnel. Another application is to extend existing EAP methods with
+ new features such as EAP channel bindings.
+
+ Great care must be taken when using tunnels with no server
+ authentication for the protection of an inner method. For example,
+ the client may lack the appropriate trust roots to fully authenticate
+ the server, but may still establish the tunnel to execute an inner
+ EAP method to perform mutual authentication and key derivation. In
+ these cases, the inner EAP method MUST provide resistance to
+ dictionary attack and a cryptographic binding between the inner
+ method and the tunnel method MUST be established. Furthermore, the
+ cipher suite used to establish the tunnel MUST derive the master key
+ using contributions from both client and server, as in ephemeral
+ Diffie-Hellman cipher suites.
+
+ The tunnel method MAY allow for certificate-less authentication.
+
+
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 8]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+4. Requirements
+
+4.1. General Requirements
+
+4.1.1. RFC Compliance
+
+ The tunnel method MUST include a Security Claims section with all
+ security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In
+ addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC
+ 3748 that tunnel methods MUST support protection against man-in-the-
+ middle attacks. Furthermore, the tunnel method MUST support identity
+ protection as specified in Section 7.3 of RFC 3748.
+
+ The tunnel method MUST be unconditionally compliant with RFC 4017
+ [RFC4017] (using the definition of "unconditionally compliant"
+ contained in Section 1.1 of RFC 4017). This means that the method
+ MUST satisfy all the "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT"
+ requirements in RFC 4017.
+
+ The tunnel method MUST meet all the "MUST" and "SHOULD" requirements
+ relevant to EAP methods contained in the EAP key management framework
+ [RFC5247] or any successor. This includes the generation of the
+ Master Session Key (MSK), Extended Master Session Key (EMSK),
+ Peer-Id, Server-Id, and Session-Id. These requirements will enable
+ the tunnel method to properly fit into the EAP key management
+ framework, maintaining all of the security properties and guarantees
+ of that framework.
+
+ The tunnel method MUST NOT be tied to any single cryptographic
+ algorithm. Instead, it MUST support run-time negotiation to select
+ among an extensible set of cryptographic algorithms, such as
+ algorithms used with certificates presented during tunnel
+ establishment. This "cryptographic algorithm agility" provides
+ several advantages. Most important, when a weakness in an algorithm
+ is discovered or increased processing power overtakes an algorithm,
+ users can easily transition to a new algorithm. Also, users can
+ choose the algorithm that best meets their needs.
+
+ The tunnel method MUST meet the SHOULD and MUST requirements
+ pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962].
+ This includes: cryptographic algorithm independence; strong, fresh
+ session keys; replay detection; keying material confidentiality and
+ integrity; and confirmation of cipher suite selection.
+
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 9]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+4.2. Tunnel Requirements
+
+ The following section discusses requirements for TLS tunnel
+ establishment.
+
+4.2.1. TLS Requirements
+
+ The tunnel-based method MUST support TLS version 1.2 [RFC5246] and
+ may support earlier versions greater than SSL 2.0 in order to enable
+ the possibility of backwards compatibility.
+
+4.2.1.1. Cipher Suites
+
+4.2.1.1.1. Cipher Suite Negotiation
+
+ Cipher suite negotiations always suffer from downgrading attacks when
+ they are not secured by any kind of integrity protection. A common
+ practice is a post-negotiation integrity check in which, as soon as
+ available, the established keys (here, the tunnel key) are used to
+ derive integrity keys. These integrity keys are then used by the
+ peer and authentication server to verify whether the cipher suite
+ negotiation has been maliciously altered by another party.
+
+ Integrity checks prevent downgrading attacks only if the derived
+ integrity keys and the employed integrity algorithms cannot be broken
+ in real-time. See Section 5.1 or [HC07] for more information on
+ this. Hence, the tunnel method MUST provide integrity-protected
+ cipher suite negotiation with secure integrity algorithms and
+ integrity keys.
+
+ TLS provides protected cipher suite negotiation as long as all the
+ cipher suites supported provide authentication, key establishment,
+ and data integrity protection as discussed in Section 5.1.
+
+4.2.1.1.2. Tunnel Data Protection Algorithms
+
+ In order to prevent attacks on the cryptographic algorithms employed
+ by inner authentication methods, a tunnel protocol's protection needs
+ to provide a basic level of algorithm strength. The tunnel method
+ MUST provide at least one mandatory-to-implement cipher suite that
+ provides the equivalent security of 128-bit AES for encryption and
+ message authentication. See Part 1 of the NIST "Recommendation for
+ Key Management" [NIST-SP-800-57] for a discussion of the relative
+ strengths of common algorithms.
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 10]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+4.2.1.1.3. Tunnel Authentication and Key Establishment
+
+ A tunnel method MUST provide unidirectional authentication from
+ authentication server to EAP peer and mutual authentication between
+ authentication server and EAP peer. The tunnel method MUST provide
+ at least one mandatory-to-implement cipher suite that provides
+ certificate-based authentication of the server and provides optional
+ certificate-based authentication of the client. Other types of
+ authentication MAY be supported.
+
+ At least one mandatory-to-implement cipher suite MUST be approved by
+ the NIST "Draft Recommendation for Key Management", Part 3
+ [NIST-SP-800-57p3], i.e., the cipher suite MUST be listed in Table
+ 4-1, 4-2, or 4-3 in that document.
+
+ The mandatory-to-implement cipher suites MUST only include cipher
+ suites that use strong cryptographic algorithms. They MUST NOT
+ include cipher suites providing mutually anonymous authentication or
+ static Diffie-Hellman cipher suites.
+
+ Other cipher suites MAY be selected following the security
+ requirements for tunnel protocols in the NIST "Recommendation for EAP
+ Methods Used in Wireless Network Access Authentication"
+ [NIST-SP-800-120].
+
+4.2.1.2. Tunnel Replay Protection
+
+ In order to prevent replay attacks on a tunnel protocol, the message
+ authentication MUST be generated using a time-variant input such as
+ timestamps, sequence numbers, nonces, or a combination of these, so
+ that any reuse of the authentication data can be detected as invalid.
+ TLS provides sufficient replay protection to meet this requirement as
+ long as weak cipher suites discussed in Section 5.1 are avoided.
+
+4.2.1.3. TLS Extensions
+
+ In order to meet the requirements in this document, TLS extensions
+ MAY be used. For example, TLS extensions may be useful in providing
+ certificate revocation information via the TLS Online Certificate
+ Status Protocol (OCSP) extension [RFC6066] (thus meeting the
+ requirement in Section 4.5.1.3).
+
+4.2.1.4. Peer Identity Privacy
+
+ A tunnel protocol MUST support peer privacy. This requires that the
+ username and other attributes associated with the peer are not
+ transmitted in the clear or to an unauthenticated, unauthorized
+ party. Peer identity protection provided by the tunnel method
+
+
+
+Hoeper, et al. Informational [Page 11]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+ applies to establishment of the tunnel and protection of inner method
+ specific identities. If applicable, the peer certificate is sent
+ confidentially (i.e., encrypted).
+
+4.2.1.5. Session Resumption
+
+ The tunnel method MUST support TLS session resumption as defined in
+ [RFC5246]. The tunnel method MAY support other methods of session
+ resumption such as those defined in [RFC5077].
+
+4.2.2. Fragmentation
+
+ Tunnel establishment sometimes requires the exchange of information
+ that exceeds what can be carried in a single EAP message. In
+ addition, information carried within the tunnel may also exceed this
+ limit. Therefore, a tunnel method MUST support fragmentation and
+ reassembly.
+
+4.2.3. Protection of Data External to Tunnel
+
+ A man-in-the-middle attacker can modify cleartext values such as
+ protocol version and type code information communicated outside the
+ TLS tunnel. The tunnel method MUST provide implicit or explicit
+ protection of the protocol version and type code. If modification of
+ other information external to the tunnel can cause exploitable
+ vulnerabilities, the tunnel method MUST provide protection against
+ modification of this additional data.
+
+4.3. Tunnel Payload Requirements
+
+ This section describes the payload requirements inside the tunnel.
+ These requirements frequently express features that a candidate
+ protocol must be capable of offering so that a deployer can decide
+ whether to make use of that feature. This section does not state
+ requirements about what features of each protocol must be used during
+ a deployment.
+
+4.3.1. Extensible Attribute Types
+
+ The payload MUST be extensible. Some standard payload attribute
+ types will be defined to meet known requirements listed below, such
+ as password authentication, inner EAP method, vendor-specific
+ attributes, and result indication. Additional payload attributes MAY
+ be defined in the future to support additional features and data
+ types.
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 12]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+4.3.2. Request/Challenge Response Operation
+
+ The payload MUST support the request and response type of half-duplex
+ operation typical of EAP. Multiple attributes may be sent in a
+ single payload. The payload MAY support transporting multiple
+ authentications in a single payload packet.
+
+4.3.3. Indicating Criticality of Attributes
+
+ It is expected that new attributes will be defined to be carried
+ within the tunnel method. In some cases, it is necessary for the
+ sender to know if the receiver did not understand the attribute. To
+ support this, there MUST be a way for the sender to mark attributes
+ such that the receiver will indicate if an attribute is not
+ understood.
+
+4.3.4. Vendor-Specific Support
+
+ The payload MUST support communication of an extensible set of
+ vendor-specific attributes. These attributes will be segmented into
+ uniquely identified vendor-specific namespaces. They can be used for
+ experiments or vendor-specific features.
+
+4.3.5. Result Indication
+
+ The payload MUST support result indication and its acknowledgement,
+ so both the EAP peer and server will end up with a synchronized
+ state. The result indication is needed after each chained inner
+ authentication method and at the end of the authentication, so
+ separate result indications for intermediate and final results MUST
+ be supported.
+
+4.3.6. Internationalization of Display Strings
+
+ The payload MAY provide a standard attribute format that supports
+ international strings. This attribute format MUST support encoding
+ strings in UTF-8 [RFC3629] format. Any strings sent by the server
+ intended for display to the user MUST be sent in UTF-8 format and
+ SHOULD be able to be marked with language information and adapted to
+ the user's language preference as indicated by RFC 5646 [RFC5646].
+ Note that in some cases, such as when transmitting error codes, it is
+ acceptable to exchange numeric codes that can be translated by the
+ client to support the particular local language. These numeric codes
+ are not subject to internationalization during transmission.
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 13]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+4.4. EAP Channel Binding Requirements
+
+ The tunnel method MUST be capable of meeting EAP channel binding
+ requirements described in [RFC6677]. As discussed in [RFC5056], EAP
+ channel bindings differ from channel bindings discussed in other
+ contexts. Cryptographic binding between the TLS tunnel and the inner
+ method discussed in Section 4.6.3 relates directly to the non-EAP
+ channel binding concepts discussed in RFC 5056.
+
+4.5. Requirements Associated with Carrying Username and Passwords
+
+ This section describes the requirements associated with tunneled
+ password authentication. The password authentication mentioned here
+ refers to user or machine authentication using a legacy password
+ database or verifier, such as the Lightweight Directory Access
+ Protocol (LDAP) [RFC4511], OTP, etc. These typically require the
+ password in its original text form in order to authenticate the peer;
+ hence, they require the peer to send the cleartext username and
+ password to the EAP server.
+
+4.5.1. Security
+
+ Many internal EAP methods have the peer send its password in the
+ clear to the EAP server. Other methods (e.g., challenge-response
+ methods) are vulnerable to attacks if an eavesdropper can intercept
+ the traffic. For any such methods, the security measures in the
+ following sections MUST be met.
+
+4.5.1.1. Confidentiality and Integrity
+
+ The cleartext password exchange MUST be integrity and confidentiality
+ protected. As long as the password exchange occurs inside an
+ authenticated and encrypted tunnel, this requirement is met.
+
+4.5.1.2. Authentication of Server
+
+ The EAP server MUST be authenticated before the peer sends the
+ cleartext password to the server.
+
+4.5.1.3. Server Certificate Revocation Checking
+
+ When certificate authentication is used during tunnel establishment,
+ the EAP peer may need to present its password to the server before it
+ has network access to check the revocation status of the server's
+ credentials. Therefore, the tunnel method MUST support mechanisms to
+ check the revocation status of a credential. The tunnel method
+ SHOULD make use of Online Certificate Status Protocol (OCSP)
+
+
+
+
+Hoeper, et al. Informational [Page 14]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+ [RFC2560] or Server-based Certificate Validation Protocol (SCVP)
+ [RFC5055] to obtain the revocation status of the EAP server
+ certificate.
+
+4.5.2. Internationalization
+
+ The password authentication exchange MUST support usernames and
+ passwords in international languages. It MUST support encoding of
+ username and password strings in UTF-8 [RFC3629] format. The method
+ MUST specify how username and password normalizations and/or
+ comparisons are performed in reference to SASLprep [RFC4013],
+ Net-UTF-8 [RFC5198], or their replacements.
+
+ Any strings sent by the server intended for display to the user MUST
+ be sent in UTF-8 format and SHOULD be able to be marked with language
+ information and adapted to the user's language preference as
+ indicated by RFC 5646 [RFC5646]. Note that, in some cases, such as
+ when transmitting error codes, it is acceptable to exchange numeric
+ codes that can be translated by the client to support the particular
+ local language. These numeric codes are not subject to
+ internationalization during transmission.
+
+4.5.3. Metadata
+
+ The password authentication exchange SHOULD support additional
+ associated metadata that can be used to indicate whether the
+ authentication is for a user or a machine. This allows the EAP
+ server and peer to request and negotiate authentication specifically
+ for a user or machine. This is useful in the case of multiple inner
+ authentications where the user and machine both need to be
+ authenticated.
+
+4.5.4. Password Change
+
+ The password authentication exchange MUST support password change.
+ The exchange SHOULD be extensible to support other "housekeeping"
+ functions, such as the management of PINs or other data, required by
+ some systems.
+
+4.6. Requirements Associated with Carrying EAP Methods
+
+ The tunnel method MUST be able to carry inner EAP methods without
+ modifying them. EAP methods MUST NOT be redefined inside the tunnel.
+
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 15]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+4.6.1. Method Negotiation
+
+ The tunnel method MUST support the protected negotiation of the inner
+ EAP method. It MUST NOT allow the inner EAP method negotiation to be
+ manipulated by intermediaries.
+
+4.6.2. Chained Methods
+
+ The tunnel method SHOULD support the chaining of multiple EAP
+ methods. The tunnel method MUST allow for the communication of
+ intermediate results and for the verification of compound binding
+ between executed inner methods when chained methods are employed.
+
+4.6.3. Cryptographic Binding with the TLS Tunnel
+
+ The tunnel method MUST provide a mechanism to bind the tunnel
+ protocol and the inner EAP method. This property is referred to as
+ cryptographic binding. Such bindings are an important tool for
+ mitigating the tunnel MitM attacks [TUNNEL-MITM]. Cryptographic
+ bindings enable the complete prevention of tunnel MitM attacks
+ without the need of additional security policies, as long as the
+ inner method derives keys and is not vulnerable to attacks outside a
+ protected tunnel [LCN-2010]. Even though weak or non-key-deriving
+ inner methods may be permitted. Thus, security policies preventing
+ tunnel MitM attacks are still necessary, and the tunnel method MUST
+ provide cryptographic bindings, because only this allows migrating to
+ more secure, policy-independent implementations.
+
+ Cryptographic bindings are typically achieved by securely mixing the
+ established keying material (say, tunnel key TK) from the tunnel
+ protocol with the established keying material (say, method key MK)
+ from the inner authentication method(s) in order to derive fresh
+ keying material. If chained EAP methods are executed in the tunnel,
+ all derived inner keys are combined with the tunnel key to create a
+ new compound tunnel key (CTK). In particular, CTK is used to derive
+ the EAP MSK, EMSK and other transient keys (shown as "TEK" below),
+ such as transient encryption keys and integrity protection keys. The
+ key hierarchy for tunnel method executions that derive compound keys
+ for the purpose of cryptographic binding is depicted in Figure 1.
+
+ In the case of the sequential executions of n inner methods, a
+ chained compound key CTK_i MUST be computed upon the completion of
+ each inner method i such that it contains the compound key of all
+ previous inner methods, i.e., CTK_i=f(CTK_i-1, MK_i) with 0 < i <= n
+ and CTK_0=TK, where f() is a key derivation function, such as one
+ that complies with the NIST "Recommendation for Key Derivation Using
+ Pseudorandom Functions" [NIST-SP-800-108]. CTK_n SHOULD serve as the
+ key to derive further keys. Figure 1 depicts the key hierarchy in
+
+
+
+Hoeper, et al. Informational [Page 16]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+ the case of a single inner method. Transient keys derived from the
+ compound key CTK are used in a cryptographic protocol to verify the
+ integrity of the tunnel and the inner authentication method.
+
+ -----------
+ | TK | MK |
+ -----------
+ | |
+ v v
+ --------
+ | CTK |
+ --------
+ |
+ v
+ ----------------
+ | | |
+ v v v
+ ------- ------ -------
+ | TEK | | MSK | | EMSK |
+ ------- ------- --------
+
+ Figure 1: Compound Keys
+
+ Furthermore, all compound keys CTK_i and all keys derived from it
+ SHOULD follow the recommendations for key derivations and key
+ hierarchies as specified in [NIST-SP-800-108]. In particular, all
+ derived keys MUST have a lifetime assigned that does not exceed the
+ lifetime of any key higher in the key hierarchy. The derivation MUST
+ prevent a compromise in one part of the system from leading to
+ compromises in other parts of the system that relay on keys at the
+ same or higher level in the hierarchy.
+
+4.6.4. Peer-Initiated EAP Authentication
+
+ The tunnel method SHOULD allow for the peer to initiate an inner EAP
+ authentication in order to meet its policy requirements for
+ authenticating the server.
+
+4.6.5. Method Metadata
+
+ The tunnel method SHOULD allow for the communication of additional
+ data associated with an EAP method. This can be used to indicate
+ whether the authentication is for a user or a machine. This allows
+ the EAP server and peer to request and negotiate authentication
+ specifically for a user or machine. This is useful in the case of
+ multiple inner EAP authentications where the user and machine both
+ need to be authenticated.
+
+
+
+
+Hoeper, et al. Informational [Page 17]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+5. Security Considerations
+
+ A tunnel method is often deployed to provide mutual authentication
+ between EAP Peer and EAP Server and to generate key material for use
+ in protecting lower-layer protocols. In addition the tunnel is used
+ to protect the communication of additional data, including peer
+ identity between the EAP Peer and EAP Server from disclosure to or
+ modification by an attacker. These sections cover considerations
+ that affect the ability for a method to achieve these goals.
+
+5.1. Cipher Suite Selection
+
+ TLS supports a wide range of cipher suites providing a variety of
+ security properties. The selection of cipher suites is critical to
+ the security of the tunnel method. Selection of a cipher suite with
+ weak or no authentication, such as an anonymous Diffie-Hellman-based
+ cipher suite, will greatly increase the risk of system compromise.
+ Since a tunnel method uses the TLS tunnel to transport data, the
+ selection of a cipher suite with weak data encryption and integrity
+ algorithms will also increase the vulnerability of the method to
+ attacks.
+
+ A tunnel protocol is prone to downgrading attacks if the tunnel
+ protocol supports any key establishment algorithm that can be broken
+ on-line. In a successful downgrading attack, an adversary breaks the
+ selected "weak" key establishment algorithm and optionally the "weak"
+ authentication algorithm without being detected. Here, "weak" refers
+ to a key establishment algorithm that can be broken in real-time, and
+ an authentication scheme that can be broken off-line, respectively.
+ See [HC07] for more details. The requirements in this document
+ disapprove the use of key establishment algorithms that can be broken
+ on-line.
+
+ Mutually anonymous tunnel protocols are prone to man-in-the-middle
+ attacks described in [HC07]. During such an attack, an adversary
+ establishes one tunnel with the peer and one with the authentication
+ server, while the peer and server believe that they established a
+ tunnel with each other. Once both tunnels have been established, the
+ adversary can eavesdrop on all communications within the tunnels,
+ i.e., the execution of the inner authentication method(s).
+ Consequently, the adversary can eavesdrop on the identifiers that are
+ exchanged as part of the EAP method, and thus the privacy of peer
+ and/or authentication server is compromised along with any other data
+ transmitted within the tunnels. This document requires server
+ authentication to avoid the risks associated with anonymous cipher
+ suites.
+
+
+
+
+
+Hoeper, et al. Informational [Page 18]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+5.2. Tunneled Authentication
+
+ In many cases, a tunnel method provides mutual authentication by
+ authenticating the server during tunnel establishment and
+ authenticating the peer within the tunnel using an EAP method. As
+ described in [TUNNEL-MITM], this mode of operation can allow tunnel
+ man-in-the-middle attackers to authenticate to the server as the peer
+ by tunneling the inner EAP protocol messages to and from a peer that
+ is executing the method outside a tunnel or with an untrustworthy
+ server. Cryptographic binding between the established keying
+ material from the inner authentication method(s) and the tunnel
+ protocol verifies that the endpoints of the tunnel and the inner
+ authentication method(s) are the same. This can thwart the attack if
+ the inner-method-derived keys are of sufficient strength that they
+ cannot be broken in real-time.
+
+ In cases where the inner authentication method does not generate any
+ key material or only weak key material, security policies MUST be
+ enforced such that the peer cannot execute the inner method with the
+ same credentials outside a protective tunnel or with an untrustworthy
+ server.
+
+5.3. Data External to Tunnel
+
+ The tunnel method will use data that is outside the TLS tunnel such
+ as the EAP type code or version numbers. If an attacker can
+ compromise the protocol by modifying these values, the tunnel method
+ MUST protect this data from modification. In some cases, external
+ data may not need additional protection because it is implicitly
+ verified during the protocol operation.
+
+5.4. Separation of TLS Tunnel and Inner Authentication Termination
+
+ Terminating the inner method at a different location than the outer
+ tunnel needs careful consideration. The inner method data may be
+ vulnerable to modification and eavesdropping between the server that
+ terminates the tunnel and the server that terminates the inner
+ method. For example, if a cleartext password is used, then it may be
+ sent to the inner method server in a RADIUS password attribute, which
+ uses weak encryption that may not be suitable protection for many
+ environments.
+
+ In some cases, terminating the tunnel at a different location may
+ make it difficult for a peer to authenticate the server and trust it
+ for further communication. For example, if the TLS tunnel is
+ terminated by a different organization, the peer needs to be able to
+ authenticate and authorize the tunnel server to handle secret
+
+
+
+
+Hoeper, et al. Informational [Page 19]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+ credentials that the peer shares with the home server that terminates
+ the inner method. This may not meet the security policy of many
+ environments.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
+ C. Adams, "X.509 Internet Public Key Infrastructure
+ Online Certificate Status Protocol - OCSP", RFC 2560,
+ June 1999.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
+ H. Levkowetz, "Extensible Authentication Protocol
+ (EAP)", RFC 3748, June 2004.
+
+ [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
+ Authentication Protocol (EAP) Method Requirements for
+ Wireless LANs", RFC 4017, March 2005.
+
+ [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
+ Authorization, and Accounting (AAA) Key Management",
+ BCP 132, RFC 4962, July 2007.
+
+ [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
+ W. Polk, "Server-Based Certificate Validation Protocol
+ (SCVP)", RFC 5055, December 2007.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246, August
+ 2008.
+
+ [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
+ Authentication Protocol (EAP) Key Management
+ Framework", RFC 5247, August 2008.
+
+ [RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel
+ Binding Support for Extensible Authentication Protocol
+ (EAP) Methods", RFC 6677, July 2012.
+
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 20]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+6.2. Informative References
+
+ [EAP-ENROLL] Mahy, R., "An Extensible Authentication Protocol (EAP)
+ Enrollment Method", Work in Progress, March 2006.
+
+ [HC07] Hoeper, K. and L. Chen, "Where EAP Security Claims
+ Fail", Institute for Computer Sciences, Social
+ Informatics and Telecommunications Engineering (ICST),
+ The Fourth International Conference on Heterogeneous
+ Networking for Quality, Reliability, Security and
+ Robustness (QShine 2007), August 2007.
+
+ [LCN-2010] Hoeper, K. and L. Chen, "An Inconvenient Truth about
+ Tunneled Authentications", Proceedings of 35th Annual
+ IEEE Conference on Local Computer Networks (LCN 2010),
+ September 2009.
+
+ [NIST-SP-800-108]
+ Chen, L., "Recommendation for Key Derivation Using
+ Pseudorandom Functions", Draft NIST Special Publication
+ 800-108, April 2008.
+
+ [NIST-SP-800-120]
+ Hoeper, K. and L. Chen, "Recommendation for EAP Methods
+ Used in Wireless Network Access Authentication", NIST
+ Special Publication 800-120, September 2009.
+
+ [NIST-SP-800-57]
+ Barker, E., Barker, W., Burr, W., Polk, W., and M.
+ Smid, "Recommendation for Key Management - Part 1:
+ General (Revised)", NIST Special Publication 800-57,
+ part 1, March 2007.
+
+ [NIST-SP-800-57p3]
+ Barker, E., Burr, W., Jones, A., Polk, W., Rose, S.,
+ and M. Smid, "Recommendation for Key Management, Part 3
+ Application-Specific Key Management Guidance", Draft
+ NIST Special Publication 800-57, part 3, October 2008.
+
+ [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
+ Authentication Protocol (PEAP) Specification", August
+ 2009, <http:// download.microsoft.com/download/9/5/E/
+ 95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-
+ PEAP%5D.pdf>.
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
+ Names and Passwords", RFC 4013, February 2005.
+
+
+
+
+Hoeper, et al. Informational [Page 21]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+ [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
+ Network Access Identifier", RFC 4282, December 2005.
+
+ [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
+ (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
+ "The Flexible Authentication via Secure Tunneling
+ Extensible Authentication Protocol Method (EAP-FAST)",
+ RFC 4851, May 2007.
+
+ [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
+ Channels", RFC 5056, November 2007.
+
+ [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
+ "Transport Layer Security (TLS) Session Resumption
+ without Server-Side State", RFC 5077, January 2008.
+
+ [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for
+ Network Interchange", RFC 5198, March 2008.
+
+ [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and
+ J. Tardo, "Network Endpoint Assessment (NEA): Overview
+ and Requirements", RFC 5209, June 2008.
+
+ [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible
+ Authentication Protocol Tunneled Transport Layer
+ Security Authenticated Protocol Version 0 (EAP-
+ TTLSv0)", RFC 5281, August 2008.
+
+ [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
+ Languages", BCP 47, RFC 5646, September 2009.
+
+ [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan,
+ "PB-TNC: A Posture Broker (PB) Protocol Compatible with
+ Trusted Network Connect (TNC)", RFC 5793, March 2010.
+
+ [RFC6066] Eastlake, D., "Transport Layer Security (TLS)
+ Extensions: Extension Definitions", RFC 6066, January
+ 2011.
+
+ [TUNNEL-MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-
+ Middle in Tunnelled Authentication Protocols",
+ Cryptology ePrint Archive: Report 2002/163, November
+ 2002.
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 22]
+
+RFC 6678 EAP Tunnel Method Requirements July 2012
+
+
+Authors' Addresses
+
+ Katrin Hoeper
+ Motorola Solutions, Inc.
+ 1301 E. Algonquin Road
+ Schaumburg, IL 60196
+ USA
+
+ EMail: khoeper@motorolasolutions.com
+
+
+ Stephen Hanna
+ Juniper Networks
+ 3 Beverly Road
+ Bedford, MA 01730
+ USA
+
+ EMail: shanna@juniper.net
+
+
+ Hao Zhou
+ Cisco Systems, Inc.
+ 4125 Highlander Parkway
+ Richfield, OH 44286
+ USA
+
+ EMail: hzhou@cisco.com
+
+
+ Joseph Salowey (editor)
+ Cisco Systems, Inc.
+ 2901 3rd. Ave
+ Seattle, WA 98121
+ USA
+
+ EMail: jsalowey@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoeper, et al. Informational [Page 23]
+