One document matched: draft-salowey-emu-eaptunnel-req-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4017 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4017.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY rfc2246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml">
<!ENTITY rfc4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
<!ENTITY rfc4106 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4106.xml">
<!ENTITY rfc3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc5077 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml">
<!ENTITY rfc4962 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4962.xml">
<!ENTITY rfc4282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml">
<!ENTITY rfc2560 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2560.xml">
<!ENTITY rfc5055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5055.xml">
<!ENTITY rfc3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY ietf-tls-rfc4346-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-rfc4346-bis.xml">
<!ENTITY ietf-nea-pb-tnc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nea-pb-tnc.xml">
<!ENTITY ietf-eap-keying SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-eap-keying.xml">
<!ENTITY funk-eap-ttls-v0 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.funk-eap-ttls-v0.xml">
<!ENTITY mahy-eap-enrollment SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mahy-eap-enrollment.xml">
<!ENTITY ietf-nea-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nea-requirements.xml">
<!ENTITY clancy-emu-chbind SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.clancy-emu-chbind.xml">
<!ENTITY rfc4851 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4851.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<rfc ipr="full3978" category="info" docName="draft-salowey-emu-eaptunnel-req-01.txt">
<front>
<title abbrev="EAP Tunnel Method Requirements">Requirements for an Tunnel Based EAP Method</title>
<author fullname="Katrin Hoeper" initials="K" surname="Hoeper">
<organization>NIST</organization>
<address>
<postal>
<street>100 Bureau Drive, MS: 8930</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899</code>
<country>USA</country>
</postal>
<email>khoeper@nist.gov</email>
</address>
</author>
<author fullname="Stephen Hanna" initials="S" surname="Hanna">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>3 Beverly Road</street>
<city>Bedford</city>
<region>MA</region>
<code>01730</code>
<country>USA</country>
</postal>
<email>shanna@juniper.net</email>
</address>
</author>
<author fullname="Hao Zhou" initials="H" surname="Zhou">
<organization abbrev="">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>4125 Highlander Parkway</street>
<city>Richfield</city>
<country>USA</country>
<code>44286</code>
<region>OH</region>
</postal>
<email>hzhou@cisco.com</email>
</address>
</author>
<author fullname="Joseph Salowey" initials="J" surname="Salowey" role="editor">
<organization> Cisco Systems, Inc.</organization>
<address>
<postal>
<street>2901 3rd. Ave</street>
<city>Seattle</city>
<code>98121</code>
<region>WA</region>
<country>USA</country>
</postal>
<email> jsalowey@cisco.com </email>
</address>
</author>
<date month="June" year="2008"/>
<area> Security Area </area>
<workgroup> EMU Working Group </workgroup>
<abstract>
<t> This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This 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. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Running EAP methods within a TLS protected tunnel has been deployed in several different solutions. EAP methods supporting this include PEAP, <xref target="I-D.funk-eap-ttls-v0">TTLS</xref> and <xref target="RFC4851">EAP-FAST</xref>. 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 a 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.</t>
<t>This document describes the requirements for an EAP tunnel method as well as for a password protocol supporting legacy password databases within the tunnel method.</t>
</section>
<section title="Conventions Used In This Document">
<t>Because this specification is an informational specification
(not able to directly use <xref target="RFC2119"></xref>), the following capitalized
words are used to express requirements language used in this
specification. Use of each capitalized word within a sentence
or phrase carries the following meaning during the EMU WG's
method selection process:</t>
<list>
<t><vspace>1</vspace>MUST - indicates an absolute requirement </t>
<t><vspace>1</vspace>MUST NOT - indicates something absolutely prohibited </t>
<t><vspace>1</vspace>SHOULD - indicates a strong recommendation of a desired result</t>
<t><vspace>1</vspace>SHOULD NOT - indicates a strong recommendation against a result</t>
<t><vspace>1</vspace>MAY - indicates a willingness to allow an optional outcome</t>
</list>
<t>Lower case uses of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and
"MAY" carry their normal meaning and are not subject to these
definitions. </t>
</section>
<section title="Use Cases">
<t>To motivate and explain the requirements in this document, a representative set of use cases for the EAP tunnel method are supplied here. The candidate tunnel method is expected to meet all of the use cases marked as MUST.</t>
<section title="Password Authentication">
<t>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. Example of such systems are 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 meet this use case. However, it MUST NOT expose the username and password to untrusted parties and it MUST provide protection against man-in-the-middle and dictionary attacks.</t>
<t>Since EAP authentication occurs before network access is granted the tunnel method SHOULD provide support for minimal password management tasks including password change, "new PIN mode", and "next token mode" required by some systems.</t>
</section>
<section title="Protect Weak EAP Methods">
<t>Some existing EAP methods have vulnerabilities that could be eliminated or reduced by running them inside a protected tunnel. For example, a method such as EAP-MD5 does not provide mutual authentication or protection from dictionary attacks. In addition, tunneled EAP methods are subject to a specific form of man-in-the-middle attack described in <xref target="TUNNEL-MITM"/>.</t>
<t>The tunnel method MUST support protection of weak inner methods and protect against man-in-the-middle attacks associated with tunneled authentication.</t>
</section>
<section title="Chained EAP Methods">
<t>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 that he or she is using. However, chained EAP methods from different conversations can be re-directed into the same conversation by an attacker giving the authenticator the impression that both conversations terminate at the same end-point. Cryptographic binding can be used to bind the results of key generating methods together or to an encompassing tunnel.</t> <t>The tunnel method MUST support chained EAP methods while including strong protection against attacks on the method chaining.</t>
</section>
<section title="Identity Protection">
<t>When performing an EAP authentication, the peer may want to protect its identity, only disclosing its identity to a trusted backend authentication server. This helps to maintain the privacy of the peer's identity.</t>
<t>The tunnel method MUST support identity protection, ensuring that peer identity is not disclosed to the authenticator and any other intermediaries before the server that terminates the tunnel method. If an inner method also provides identity protection, this protection MUST extend all the way to the server that terminates that inner method. Note that the peer may need to expose the realm portion of the EAP outer identity in the NAI <xref target="RFC4282" /> in a roaming scenario in order to reach the appropriate authentication server.</t>
</section>
<section title="Emergency Services Authentication">
<t>When wireless VOIP service is provided, some regulations require any user to be able to gain access to the network to make an emergency telephone call. To avoid eavesdropping on this call, it's best to negotiate link layer security as with any other authentication.</t>
<t>Therefore, the tunnel method SHOULD allow anonymous peers or server-only authentication, but still derive 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. Forgoing 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.</t>
</section>
<section title="Network Endpoint Assessment">
<t>The Network Endpoint Assessment (NEA) protocols and reference model described in <xref target="I-D.ietf-nea-requirements" /> 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.</t>
<t>The tunnel method SHOULD support carrying NEA protocols such as PB-TNC <xref target="I-D.ietf-nea-pb-tnc" />.
Depending on the specifics of the tunnel method, these protocols may be required to be carried in an EAP method.</t>
</section>
<section title="Credential Provisioning and Enrollment">
<t>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 <xref target="I-D.mahy-eap-enrollment" />. </t>
<t>The tunnel method SHOULD support carrying credential distribution protocols.</t>
</section>
<section title="Resource Constrained Environments">
<t> A growing number of "resource constrained" devices (e.g. printers and
phones) are connecting to IP networks and those networks increasingly require EAP authentication to gain access. Therefore, it is natural to expect that new EAP methods be designed to work as well as possible with these devices.</t>
<t>For the purposes of this document, the phrase "resource constrained"
means any combination of the following constraints: little processing power, small amounts of memory (both ROM and RAM), small amounts of long-term mutable storage (e.g. flash or hard drive) or none at all, and constrained power usage (perhaps due to small battery).</t>
<t>The tunnel method SHOULD be designed so it can be configured to work with "resource constrained" devices, when possible.</t>
</section>
<section title="Client Authentication During Tunnel Establishment">
<t>In cases where client authentication can be performed as part of the tunnel establishment it is efficient for the tunnel method to allow this. The tunnel MUST be capable of providing client side authentication during tunnel establishment.
</t>
</section>
<section title="Extensibility">
<t> The tunnel method MUST provide extensibility so that additional types of data can be carried inside the tunnel in the future. This removes the need to develop new tunneling methods for specific purposes. </t>
</section>
</section>
<section title="Requirements" anchor="reqs">
<section title="General Requirements">
<section title="RFC Compliance">
<t>The tunnel method MUST include a Security Claims section with all security claims specified in Section 7.2 in <xref target="RFC3748">RFC 3748</xref>. 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, all tunnel methods MUST support identity protection as specified in Section 7.3 in RFC 3748.</t>
<t>The tunnel method MUST be unconditionally compliant with <xref target="RFC4017">RFC 4017</xref> (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.</t>
<t>The tunnel method MUST meet all the EAP method requirements contained in the EAP Key Management Framework draft <xref target="I-D.ietf-eap-keying" /> or its successor. The tunnel method MUST include MSK and EMSK generation. This 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.</t>
<t>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. 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.</t>
<t>The tunnel method MUST meet requirements pertinent to EAP method contained in Section 3 of <xref target="RFC4962">RFC 4962</xref>. This includes: cryptographic algorithm independence; strong, fresh session keys; replay detection; keying material confidentiality and integrity; confirm cipher suite selection; and uniquely named keys. In addition, the tunnel method MUST support EAP channel bindings to enable a system based on EAP to meet the additional requirements in Section 3 of RFC 4962.</t>
</section>
<section title="Draw from Existing Work">
<t>Several existing tunnel methods are already in widespread usage:
EAP-FAST <xref target="RFC4851" />, EAP-TTLS <xref target="I-D.funk-eap-ttls-v0"/>, and PEAP. Considerable experience has been gained from various deployments with these methods. This experience SHOULD be considered when evaluating tunnel methods. If one of these existing tunnel methods can meet the requirements contained in this specification then that method SHOULD be preferred over a new method.</t>
<t>Even if minor modifications or extensions to an existing tunnel method are needed, this method SHOULD be preferred over a completely new method so that the advantage of accumulated deployment experience and security analysis can be gained. </t>
</section>
</section>
<section title="Tunnel Requirements">
<t>Existing tunnel methods make use of TLS <xref target="I-D.ietf-tls-rfc4346-bis" /> to provide the protected tunnel. In general this has worked well so there is consensus to continue to use TLS as the basis for a tunnel method. </t>
<section title="TLS Requirements">
<t>The tunnel based method MUST support TLS version 1.2 <xref target="I-D.ietf-tls-rfc4346-bis" /> and SHOULD support TLS version 1.0 <xref target="RFC2246" /> and version 1.1 <xref target="RFC4346" /> to enable the possibility of backwards compatibility with existing deployments. The following section discusses requirements for TLS Tunnel Establishment.</t>
<section title="Cipher Suites">
<section title="Cipher Suite Negotiation"> <t>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 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 peer and authentication server to verify whether the cipher suite negotiation has been maliciously altered by another party.</t>
<t>Integrity checks prevent downgrading attacks only if the derived integrity keys and the employed integrity algorithms cannot be broken in real-time. See <xref target="secciph" /> or <xref target="KHLC07" /> for more information on this. Hence, the tunnel method MUST provide integrity protected cipher suite negotiation with secure integrity algorithms and integrity keys. </t>
<t> All versions of TLS meet these requirements as long as the cipher suites used provide strong authentication, key establishment and data integrity protection.
</t>
</section>
<section title="Tunnel Data Protection Algorithms">
<t>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 <xref target="NIST SP 800-57" /> for a discussion of the relative strengths of common algorithms.
</t>
</section>
<section title="Tunnel Authentication and Key Establishment" anchor="keyest">
<t>A tunnel method MUST provide unidirectional authentication from authentication server to EAP peer or 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.</t>
<t>At least one mandatory to implement cipher suite MUST meet the
following requirements for secure key establishment along with the
previous requirements for authentication and data protection
algorithms: </t>
<t><list style="symbols">
<t>One-way key derivation, i.e., a compromised key leads to
the compromise of all descendant keys but does not affect the
security of any precedent key in the same branch of the key
hierarchy. <vspace blankLines="1"/></t>
<t>Cryptographically separated keys, i.e., a compromised key in one branch of the key hierarchy
does not affect the security of keys in other branches.
<vspace blankLines="1" /> </t>
<t>Cryptographically separated entities, i.e., keys held by different entities are cryptographically separate. As a result, the
compromise of a single peer does not compromise keying
material held by any other peer within the system, including
session keys and long-term keys. <vspace blankLines="1" /></t>
<t>Identity binding, i.e., each derived key is bound to the EAP peer and authentication
server by including their identifiers as input to the key derivation.
<vspace blankLines="1" /></t>
<t>Context binding, i.e., each derived key is bound to its context by including appropriate
key labels in the input of the key derivation. <vspace blankLines="1" /></t>
<t>Key lifetime, i.e., each key has a lifetime assigned that does not exceed the
lifetime of any key higher in the key hierarchy. <vspace blankLines="1" /></t>
<t> Mutual implicit key authentication, i.e., the keying material
derived upon a successful key establishment execution is only
known to the EAP peer and authentication server and is kept
confidential.
<vspace blankLines="1" /></t>
<t>Key freshness, i.e. EAP peer and EAP server are assured that the
derived keys are fresh and the re-use of expired key material is
prevented. The freshness property is typically achieved by using
one or more of the following techniques: nonces, sequence numbers,
timestamps. <vspace blankLines="1" /></t>
</list></t>
<t>The mandatory to implement cipher suites MUST NOT
include "export strength" cipher suites, cipher suites providing mutually anonymous authentication
or static Diffie-Hellman cipher suites. NIST publication <xref target="NIST SP 800-52" /> can be consulted for a list of
acceptable TLS v1.0 cipher suites and <xref target="NIST SP 800-108" /> for additional information on secure key derivation.</t>
<t>In addition a tunnel method SHOULD provide cipher suites to meet the following additional recommendations for good key establishment algorithms: </t>
<t><list style="symbols">
<t>Key control , i.e., EAP peer and authentication server each contribute
to the key computation of the tunnel key. This property prevents
that a single protocol participant controls the value of an
established key. In that way, protocol participants can ensure
that generated keys are fresh and have good random properties. <vspace blankLines="1" /></t>
<t>Key confirmation, i.e., one protocol participant is assured that
another participant actually possesses a particular secret key.
In the case of mutual key confirmation both the EAP peer and the
authentication server are assured that they possess the same key.
Key confirmation is commonly achieved by using one of the derived
keys to generate a message authentication code. Mutual key
confirmation combined with mutual implicit key authentication
leads to mutual explicit key authentication.
<vspace blankLines="1" /></t>
<t>Forward secrecy (FS), i.e., if a long-term secret key is
compromised, it does not compromise keys that have been
established in previous EAP executions. This property is
typically achieved by executing an ephemeral Diffie-Hellman key
establishment. <vspace blankLines="1" /></t>
</list>
</t>
</section>
</section>
<section title="Tunnel Replay Protection">
<t>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 re-use of the authentication data can be detected as invalid. TLS makes use of an 8 byte sequence number to protect against replay. </t>
</section>
<section title="TLS Extensions">
<t>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 OCSP extension (thus meeting the requirement in <xref target="revocation" />).</t>
</section>
<section title="Peer Identity Privacy">
<t>A tunnel protocol MUST support peer privacy. This requires that the username is not transmitted in the clear and, if applicable, the peer certificate is sent confidentially (i.e. encrypted). </t>
</section>
<section title="Session Resumption">
<t>The tunnel method MUST support TLS session resumption as defined in <xref target="I-D.ietf-tls-rfc4346-bis"/>. The tunnel method MAY support other methods of session resumption such as those defined in <xref target="RFC5077" />. </t>
</section>
</section>
<section title="Fragmentation">
<t>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. </t>
</section>
<section title="EAP Header Protection">
<t>A tunnel method SHOULD provide protection of the outer EAP header information when possible to make sure the outer EAP header is not modified by the intermediaries.</t>
</section>
</section>
<section title="Tunnel Payload Requirements">
<t>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. </t>
<section title="Extensible Attribute Types">
<t> 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.</t>
</section>
<section title="Request/Challenge Response Operation">
<t>The payload MUST support request and response type of half-duplex operation typical of EAP. Multiple attributes may be sent in a single payload. The payload MAY support carrying on multiple authentications in a single payload packet.</t>
</section>
<section title="Mandatory and Optional Attributes">
<t>The payload MUST support marking of mandatory and optional attributes, as well as an attribute used for rejecting mandatory attributes. Mandatory attributes are attributes sent by the requester that the responder is expected to understand and MUST respond to. If the responder does not understand or support one of the mandatory attributes in the request, it MUST ignore the rest of the attributes and send a NAK attribute to decline the request. The NAK attribute MUST support inclusion of which mandatory attribute is not supported. The optional attributes are attributes that are not mandatory to support and respond to. If the responder does not understand or support the optional attributes, it can ignore these attributes.
</t>
</section>
<section title="Vendor Specific Support" >
<t>The payload MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identified vendor specific name spaces. They can be used for experiments or vendor specific features.</t>
</section>
<section title="Result Indication">
<t>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 indication for intermediate and final result MUST be supported.</t>
</section>
<section title="Internationalization of Display Strings">
<t>The payload MAY provide a standard attribute format that supports international strings. This attribute format MUST support encoding strings in
UTF-8 <xref target="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.</t>
</section>
</section>
<section title="EAP Channel Binding Requirements">
<t>The so-called "lying NAS" problem is a well-documented problem with the
current Extensible Authentication Protocol (EAP) architecture <xref target="RFC3748" /> when
used with pass-through authenticators. Here, a Network Access Server (NAS),
or pass-through authenticator, may authenticate to the backend AAA
infrastructure using one set of credentials, while representing contrary
information to EAP peers.</t>
<t>Such attacks can be prevented by so-called channel bindings <xref target="I-D.clancy-emu-chbind" />, in which key channel binding characteristics are transported from the
peer to the server, allowing the server to verify whether the authenticator
has advertised valid information to the peer. The server can also respond
back with additional information that could be useful for the peer to decide
whether or not to continue its session with the serving authenticator.</t>
<t>
The tunnel method MUST be capable of supporting EAP channel bindings described above.
</t>
</section>
<section title="Requirements Associated with Carrying Username and Passwords">
<t>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, such as LDAP, OTP, etc. These legacy user databases typically require the password in its original text form in order to authenticate the peer, hence they require the peer to send the clear text user name and password to the EAP server.</t>
<section title="Security">
<t>Due to the fact that the EAP peer needs to send clear text password to the EAP server to authenticate to the legacy user database, the security measures in the following sections MUST be met.</t>
<section title="Confidentiality and Integrity">
<t>The clear text 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.
</t>
</section>
<section title="Authentication of Server">
<t>The EAP server MUST be authenticated before the peer can send the clear text user name and password to the server. </t>
</section>
<section title="Server Credential Revocation Checking" anchor="revocation">
<t>In some cases, the EAP peer needs 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) <xref target="RFC2560"/> or Server-based Certificate Validation Protocol (SCVP) <xref target="RFC5055" /> to obtain the revocation status of the EAP server certificate.</t>
</section>
</section>
<section title="Internationalization" >
<t>The password authentication exchange MUST support user names and passwords in international languages. It MUST support encoding of user name and password strings in UTF-8 <xref target="RFC3629"/> format. Any strings sent by the server during the password exchange and 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.</t>
</section>
<section title="Meta-data" >
<t>The password authentication exchange MUST support additional associated meta-data which 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.
</t>
</section>
<section title="Password Change">
<t>The password authentication exchange MUST support password change, as well as other multiple round trips exchanges like new pin mode and next token mode for OTP database.</t>
</section>
</section>
<section title="Requirements Associated with Carrying EAP Methods">
<section title="Method Negotiation">
<t> The tunnel method MUST support the protected negotiation of the inner EAP method. It MUST NOT allow the inner EAP method negotiation to be downgraded or manipulated by intermediaries.</t>
</section>
<section title="Chained Methods">
<t>The tunnel method MUST support the chaining of multiple EAP methods. The tunnel method MUST allow for the communication of intermediate result and verification of compound binding between executed inner methods when chained methods are employed.</t>
</section>
<section title="Cryptographic Binding with TLS Tunnel">
<t>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.
Without such bindings attacks are feasible on tunnel
methods <xref target="TUNNEL-MITM" /> and chained methods. </t>
<t>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 to one method key MK.
The keying material derived from mixing tunnel and method keys is also referred to as compound
key CTK. In particular, CTK is used to derive MSK, EMSK and other
transient keys TEK, such as transient encryption keys and integrity
protection keys. The key hierarchy for tunnel methods executions that derive compound keys for the purpose of cryptographic binding is depicted in
Figure 1.</t>
<figure anchor="compoundkeys"
title="Compound Keys">
<artwork><![CDATA[
-----------
| TK | MK |
-----------
| |
v v
--------
| CTK |
--------
|
v
----------------
| | |
v v v
------- ------ -------
| TEK | | MSK | | EMSK |
------- ------- --------
]]> </artwork></figure>
<t>
For every key deriving inner EAP method that completes successfully within the tunnel cryptographic binding MUST be performed similar to the following:<vspace blankLines="1" />
</t>
<list style="symbols">
<t>compute a compound key CTK using the keying material from tunnel
protocol and all tunneled inner authentication method(s) as inputs <vspace blankLines="1" /></t>
<t>use compound key CTK to derive transient keys for use in a
cryptographic protocol that verifies the integrity of the tunnel
and the inner authentication method.</t>
</list>
<t>Furthermore, the compound key CTK and all keys derived from it
SHOULD be derived in accordance to the guidelines for key derivations and key
hierarchies as specified in <xref target="keyest" />. In particular, all derived keys
MUST have a lifetime assigned that does not exceed the lifetime of any key
higher in the key hierarchy, and MUST prevent domino effects.</t>
</section>
<section title="Peer Initiated">
<t>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. </t>
</section>
<section title="Method Meta-data" >
<t>The tunnel method MUST 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. </t>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>This document has no IANA considerations.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>A tunnel method is often deployed to provide mutual authentication between EAP Peer and EAP Server and to generate strong 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.
</t>
<section title="Ciphersuite Selection" anchor="secciph" >
<t>TLS supports a wide variety of cipher suites providing a variety of
security properties. The selection of strong 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 ciphersuite with weak data encryption and
integrity algorithms will also increase the vulnerability of the
method to attacks. </t>
<t>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 <xref target="KHLC07" /> for more details. The
requirements in this document disapprove the use of key establishment
algorithms that can be broken on-line. </t>
<t>Mutually anonymous tunnel protocols are prone to man-in-the-middle attacks described in <xref target="KHLC07" />.
During such an attack, an adversary establishes a tunnel with each the peer and the
authentication server, while 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.
</t>
</section>
<section title="Tunneled Authentication">
<t>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 <xref target="TUNNEL-MITM" />, this mode of operation can allow a man-
in-the-middle to authenticate to the server as the peer by tunneling
the inner EAP protocol messages to and from a peer 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 of sufficient strength that
they cannot be broken in real-time. </t>
<t>In cases where the inner authentication method does not generate any or
only weak key material care must be taken to ensure that the peer
does not execute the inner method with the same credentials outside
a protective tunnel or with an untrustworthy server.
</t>
</section>
<section title="Outer EAP Method Header">
<t>There are several existing EAP methods which use a similar packet format to EAP-TLS. Often for the initial portions of the exchange the execution of the method is identical except for the method ID. Protection of the outer EAP header helps to avoid vulnerabilities that may arise when an attacker attempts to modify packets to make one EAP message look like one from a different method.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&ietf-tls-rfc4346-bis;
&rfc2119;
&rfc3748;
&ietf-eap-keying;
&rfc4017;
&rfc4962;
&clancy-emu-chbind;
&rfc2560;
&rfc5055;
&rfc3629;
</references>
<references title="Informative References">
&funk-eap-ttls-v0;
&rfc4851;
&ietf-nea-requirements;
&ietf-nea-pb-tnc;
&mahy-eap-enrollment;
&rfc5077;
&rfc2246;
&rfc4346;
&rfc4282;
<reference anchor="TUNNEL-MITM">
<front>
<title>Man-in-the-Middle in Tunnelled Authentication Protocols</title>
<author initials="N" surname="Asokan" />
<author initials="V" surname="Niemi" />
<author initials="K" surname="Nyberg" />
<date month="November" year="2002" />
</front>
<seriesInfo name="Cryptology ePrint Archive: " value="Report 2002/163" />
</reference>
<reference anchor="NIST SP 800-57">
<front>
<title>Recommendation for Key Management - Part 1: General (Revised)</title>
<author initials="E" surname="Barker" />
<author initials="W" surname="Barker" />
<author initials="W" surname="Burr" />
<author initials="W" surname="Polk" />
<author initials="M" surname="Smid" />
<date month="March" year="2007" />
</front>
<seriesInfo name="NIST Special Publication" value="800-57" />
</reference><reference anchor="NIST SP 800-52">
<front>
<title>Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations</title>
<author initials="C. M." surname="Chernick" />
<author initials="C" surname="Edington III" />
<author initials="M. J." surname="Fanto" />
<author initials="R" surname="Rosenthal" />
<date month="June" year="2005" />
</front>
<seriesInfo name="NIST Special Publication" value="800-52" />
</reference>
<reference anchor="NIST SP 800-108">
<front>
<title>Recommendation for Key Derivation Using Pseudorandom Functions</title>
<author initials="L" surname="Chen" />
<date month="April" year="2008" />
</front>
<seriesInfo name="Draft NIST Special Publication" value="800-108" />
</reference>
<reference anchor="KHLC07">
<front>
<title>Where EAP Security Claims Fail</title>
<author initials="K" surname="Hoeper" />
<author initials="L" surname="Chen" />
<date month="August" year="2007" />
</front>
<seriesInfo name="ICST QShine" value="" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 13:25:07 |