doc: Add RFC documents

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]
+