8. Security Considerations
Dieser Abschnitt bewahrt den RFC-Text fuer TEAPv1, einschliesslich TLS tunnel establishment, tunneled authentication, TLV formats, cryptographic calculations, IANA registries, security considerations und examples.
8. Security Considerations
TEAP is designed with a focus on wireless media, where the medium
itself is inherent to eavesdropping. Whereas in wired media an
attacker would have to gain physical access to the wired medium,
wireless media enables anyone to capture information as it is
transmitted over the air, enabling passive attacks. Thus, physical
security can not be assumed, and security vulnerabilities are far
greater. The threat model used for the security evaluation of TEAP
is defined in EAP [RFC3748].
8.1. Mutual Authentication and Integrity Protection
As a whole, TEAP provides message and integrity protection by
establishing a secure tunnel for protecting the inner method(s). The
confidentiality and integrity protection is defined by TLS and
provides the same security strengths afforded by TLS employing a
strong entropy shared master secret. The integrity of the key
generating Inner Methods executed within the TEAP tunnel is verified
through the calculation of the Crypto-Binding TLV. This ensures that
the tunnel endpoints are the same as the inner method endpoints.
Where server unauthenticated provisioning is performed, TEAP requires
that the inner provisioning method provide for both peer and server
authentication.
8.2. Method Negotiation
As is true for any negotiated EAP, EAP NAK messages used to suggest
an alternate EAP authentication method are sent unprotected and, as
such, are subject to spoofing. During unprotected EAP method
negotiation, NAK packets may be interjected as active attacks to bid-
down to a weaker form of authentication, such as EAP-MD5 (which only
provides one-way authentication and does not derive a key). Both the
peer and server should have a method selection policy that prevents
them from negotiating down to weaker methods. Inner method
negotiation resists attacks because it is protected by the mutually
authenticated TLS tunnel established. Selection of TEAP as an
authentication method does not limit the potential inner methods, so
TEAP should be selected when available.
An attacker cannot readily determine the Inner Method used, except
perhaps by traffic analysis. It is also important that peer
implementations limit the use of credentials with an unauthenticated
or unauthorized server.
8.3. Separation of Phase 1 and Phase 2 Servers
Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT
RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a
different server than the Phase 2 conversation can introduce
vulnerabilities if there is not a proper trust relationship and
protection for the protocol between the two servers. Some
vulnerabilities include:
* Loss of identity protection
* Offline dictionary attacks
* Lack of policy enforcement
* On-path active attacks (as described in [RFC7029])
There may be cases where a trust relationship exists between the
Phase 1 and Phase 2 servers, such as on a campus or between two
offices within the same company, where there is no danger in
revealing the inner identity and credentials of the peer to entities
between the two servers. In these cases, using a proxy solution
without end-to-end protection of TEAP MAY be used. The TEAP
encrypting/decrypting gateway MUST, at a minimum, provide support for
IPsec, TLS, or similar protection in order to provide confidentiality
for the portion of the conversation between the gateway and the EAP
server. In addition, separation of the TEAP servers and Inner
servers allows for crypto-binding based on the Inner Method MSK to be
thwarted as described in [RFC7029]. If the Inner Method derives an
EMSK, then this threat is mitigated as TEAP uses the Crypto-Binding
TLV to tie the inner EMSK to the TLS session via the TLS-PRF, as
described above in Section 6.
On the other hand, if the Inner Method is not deriving EMSK, as with
password authentication or unauthenticated provisioning, then this
threat still exists. Implementations therefore need to limit the use
of Inner Methods as discussed above in Section 3.6.5
8.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies
TEAP addresses the known deficiencies and weaknesses in some EAP
authentication methods. By employing a shared secret between the
peer and server to establish a secured tunnel, TEAP enables:
* Per-packet confidentiality and integrity protection
* User identity protection
* Better support for notification messages
* Protected Inner Method negotiation, including EAP methods
* Sequencing of Inner Methods, including EAP methods
* Strong mutually derived MSKs
* Acknowledged success/failure indication
* Faster re-authentications through session resumption
* Mitigation of offline dictionary attacks
* Mitigation of on-path attacks
* Mitigation of some denial-of-service attacks
It should be noted that in TEAP, as in many other authentication
protocols, a denial-of-service attack can be mounted by adversaries
sending erroneous traffic to disrupt the protocol. This is a problem
in many authentication or key agreement protocols and is therefore
noted for TEAP as well.
TEAP was designed with a focus on protected Inner Methods that
typically rely on weak credentials, such as password-based secrets.
To that extent, the TEAP authentication mitigates several
vulnerabilities, such as offline dictionary attacks, by protecting
the weak credential-based Inner Method. The protection is based on
strong cryptographic algorithms in TLS to provide message
confidentiality and integrity. The keys derived for the protection
relies on strong random challenges provided by both peer and server
as well as an established key with strong entropy. Implementations
should follow the recommendation in [RFC4086] when generating random
numbers.
8.4.1. User Identity Protection and Verification
The initial identity request response exchange is sent in cleartext
outside the protection of TEAP. Typically, the NAI [RFC7542] in the
identity response is useful only for the realm of information that is
used to route the authentication requests to the right EAP server.
This means that the identity response may contain an anonymous
identity and just contain realm information. In other cases, the
identity exchange may be eliminated altogether if there are other
means for establishing the destination realm of the request. In no
case should an intermediary place any trust in the identity
information in the identity response since it is unauthenticated and
may not have any relevance to the authenticated identity. TEAP
implementations should not attempt to compare any identity disclosed
in the initial cleartext EAP Identity response packet with those
Identities authenticated in Phase 2.
When the server is authenticated, identity request/response exchanges
sent after the TEAP tunnel is established are protected from
modification and eavesdropping by attackers. For server
unauthenticated provisioning, the outer TLS session provides little
security, and the provisioning method must provide this protection
instead.
When a client certificate is sent outside of the TLS tunnel in Phase
1, the peer MUST include Identity-Type as an Outer TLV in order to
signal the type of identity which that client certificate is for.
Further, when a client certificate is sent outside of the TLS tunnel,
the server MUST proceed with Phase 2. If there is no Phase 2 data,
then the EAP server MUST reject the session.
Issues related to confidentiality of a client certificate are
discussed above in Section 3.4.1
Note that the Phase 2 data could simply be a Result TLV with value
Success, along with a Crypto-Binding TLV. This Phase 2 data serves
as a protected success indication as discussed in [RFC9190],
Section 2.1.1
8.5. Dictionary Attack Resistance
TEAP was designed with a focus on protected Inner Methods that
typically rely on weak credentials, such as password-based secrets.
TEAP mitigates offline dictionary attacks by allowing the
establishment of a mutually authenticated encrypted TLS tunnel
providing confidentiality and integrity to protect the weak
credential-based Inner Method.
TEAP mitigates dictionary attacks by permitting Inner Methods, such
as EAP-pwd, that are not vulnerable to dictionary attacks.
TEAP implementations can mitigate online "brute force" dictionary
attempts by limiting the number of failed authentication attempts for
a particular identity.
8.5.1. Protection Against On-Path Attacks
TEAP provides protection from on-path attacks in a few ways:
1. By using a certificates or a session ticket to mutually
authenticate the peer and server during TEAP authentication Phase
1 establishment of a secure TLS tunnel.
2. When the TLS tunnel is not secured, by using the keys generated
by the Inner Method (if the Inner Methods are key generating) in
the crypto-binding exchange and in the generation of the key
material exported by the Inner Method described in Section 6.
TEAP crypto-binding does not guarantee protection from on-path
attacks if the client allows a connection to an untrusted server,
such as in the case where the client does not properly validate the
server's certificate. If the TLS cipher suite derives the master
secret solely from the contribution of secret data from one side of
the conversation (such as cipher suites based on RSA key transport),
then an attacker who can convince the client to connect and engage in
authentication can impersonate the client to another server even if a
strong Inner Method is executed within the tunnel. If the TLS cipher
suite derives the master secret from the contribution of secrets from
both sides of the conversation (such as in cipher suites based on
Diffie-Hellman), then crypto-binding can detect an attacker in the
conversation if a strong Inner Method is used.
TEAP crypto-binding does not guarantee protection from on-path
attacks when the client does not verify the server, and the Inner
Method does not produce an EMSK. The only way to close this
vulnerability is to define TEAPv2, which would then have different
crypto-binding derivations.
8.6. Protecting Against Forged Cleartext EAP Packets
EAP Success and EAP Failure packets are, in general, sent in
cleartext and may be forged by an attacker without detection. Forged
EAP Failure packets can be used to attempt to convince an EAP peer to
disconnect. Forged EAP Success packets may be used to attempt to
convince a peer that authentication has succeeded, even though the
authenticator has not authenticated itself to the peer.
By providing message confidentiality and integrity, TEAP provides
protection against these attacks. Once the peer and authentication
server (AS) initiate the TEAP authentication Phase 2, compliant TEAP
implementations MUST silently discard all cleartext EAP messages,
unless both the TEAP peer and server have indicated success or
failure using a protected mechanism. Protected mechanisms include
the TLS alert mechanism and the protected termination mechanism
described in Section 3.6.6.
The success/failure decisions within the TEAP tunnel indicate the
final decision of the TEAP authentication conversation. After a
success/failure result has been indicated by a protected mechanism,
the TEAP peer can process unprotected EAP Success and EAP Failure
messages; however, the peer MUST ignore any unprotected EAP Success
or Failure messages where the result does not match the result of the
protected mechanism.
To abide by [RFC3748], the server sends a cleartext EAP Success or
EAP Failure packet to terminate the EAP conversation. However, since
EAP Success and EAP Failure packets are not retransmitted, the final
packet may be lost. While a TEAP-protected EAP Success or EAP
Failure packet should not be a final packet in a TEAP conversation,
it may occur based on the conditions stated above, so an EAP peer
should not rely upon the unprotected EAP Success and Failure
messages.
8.7. Use of Cleartext Passwords
TEAP can carry cleartext passwords in the Basic-Password-Auth-Resp
TLV. Implementations should take care to protect this data. For
example, passwords should not normally be logged, and password data
should be securely scrubbed from memory when it is no longer needed.
8.8. Accidental or Unintended Behavior
Due to the complexity of TEAP, and the long time between [RFC7170]
and any substantial implementation, there are many accidental or
unintended behaviors in the protocol.
The first one is that EAP-FAST-MSCHAPv2 is used instead of EAP-
MSCHAPv2. While [RFC7170] defined TEAP to use EAP-MSCHAPv2, an early
implementor or implementors instead used EAP-FAST-MSCHAPv2. The
choice for this document was either to define a new version of TEAP
that used EAP-MSCHAPv2 or instead to document implemented behavior.
The choice taken here was to document running code.
The issues discussed in Section 6.2.5 could have security impacts,
but no analysis has been performed. The choice of using a special
"all zero" IMSK in Section 6.2 was made for simplicity but could also
have negative security impacts.
The definition of the Crypto-Binding TLV means that the final Crypto-
Binding TLV values might not depend on all previous values of MSK and
EMSK. This limitation could have negative security impacts, but
again, no analysis has been performed.
We suggest that the TEAP be revised to TEAP version 2, which could
address these issues. There are proposals at this time to better
derive the various keying materials and cryptographic binding
derivations. However, in the interest of documenting running code,
we are publishing this document with the acknowledgment that there
are improvements to be made.
8.9. Implicit Challenge
Certain authentication protocols that use a challenge/response
mechanism rely on challenge material that is not generated by the
authentication server; therefore, the material may require special
handling. For EAP-TTLS, these challenges are defined in [RFC5281],
Section 11.1.
In EAP-MSCHAPv2, the authenticator issues a challenge to the
supplicant. Then, the supplicant hashes the challenge with the
password and forwards the response to the authenticator. The
response also includes a Peer-Challenge, which is created by the
supplicant. Since the challenge is random, it is not associated with
the TLS tunnel and the protocol may be susceptible to a replay
attack.
The Crypto-Binding TLV provides protection against intermediaries,
but it does not provide protection against a replay attack. We
suggest that any TEAPv2 specification correct this issue.
8.10. Security Claims
This section provides the needed security claim requirement for EAP
[RFC3748].
Auth. mechanism: Certificate-based, shared-secret-based, and various
tunneled authentication mechanisms.
Cipher Suite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes. Any method executed within the TEAP
tunnel is integrity protected. The cleartext EAP headers outside
the tunnel are not integrity protected. Server unauthenticated
provisioning provides its own protection mechanisms.
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes
Key strength: See Note 1 below.
Dictionary attack prot.: See Note 2 below.
Fast reconnect: Yes
Cryptographic binding: Yes
Session independence: Yes
Fragmentation: Yes
Key Hierarchy: Yes
Channel binding: Yes
Notes:
* Note 1. [BCP86] offers advice on appropriate key sizes. The
National Institute for Standards and Technology (NIST) also offers
advice on appropriate key sizes in [NIST-SP-800-57]. [RFC3766],
Section 6 advises use of the following required RSA or Diffie-
Hellman (DH) module and Digital Signature Algorithm (DSA) subgroup
size in bits for a given level of attack resistance in bits.
Based on the table below, a 2048-bit RSA key is required to
provide 112-bit equivalent key strength:
+==========================+===================+==============+
| Attack Resistance (bits) | RSA or DH Modulus | DSA subgroup |
| | size (bits) | size (bits) |
+==========================+===================+==============+
| 70 | 947 | 129 |
+--------------------------+-------------------+--------------+
| 80 | 1228 | 148 |
+--------------------------+-------------------+--------------+
| 90 | 1553 | 167 |
+--------------------------+-------------------+--------------+
| 100 | 1926 | 186 |
+--------------------------+-------------------+--------------+
| 150 | 4575 | 284 |
+--------------------------+-------------------+--------------+
| 200 | 8719 | 383 |
+--------------------------+-------------------+--------------+
| 250 | 14596 | 482 |
+--------------------------+-------------------+--------------+
Table 8
* Note 2. TEAP protects against offline dictionary attacks when
secure Inner Methods are used. TEAP protects against online
dictionary attacks by limiting the number of failed
authentications for a particular identity.