The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3
interacts with the EAP state machine as specified in RFC 4137. It appears
to me that this under-specification is at the root of the questions about
the commitment message.
Historically, under-specification of the EAP-TLS state machine has been a
source of potential security vulnerabilities by enabling packet injection
attacks [1][2], including attacks involving the injection of EAP-Success
and EAP-Failure mechanisms.
RFC 4137 Sections 4.1.1 and 4.1.2 define several variables:
altAccept (boolean)
Alternate indication of success, as described in [RFC3748
<https://tools.ietf.org/html/rfc3748>].
altReject (boolean)
Alternate indication of failure, as described in [RFC3748
<https://tools.ietf.org/html/rfc3748>].
eapKeyData (EAP key)
Set in peer state machine when keying material becomes available.
Set during the METHOD state. Note that this document does not
define the structure of the type "EAP key". We expect that it
will be defined in [Keying
<https://tools.ietf.org/html/rfc4137#ref-Keying>].
eapKeyAvailable (boolean)
Set to TRUE in the SUCCESS state if keying material is available.
The actual key is stored in eapKeyData.
The issue in the EAP-TLS 1.3 specification is that the interlock with
these variables is not defined.
For example, it appears to me that the commitment message verifies
that both sides are in possession of a derived key,
allowing the eapKeyData variables to be set. However, it does not
appear to me that the successful validation of the commitment message
is
sufficient to allow keys to be pushed down to the lower layer,
allowing data to flow.
Therefore the eapKeyAvailable variable should not yet be set to TRUE.
Also, the commitment message does not constitute an alternative
success indication because it is possible for an
alternative failure indication (e.g. a TLS alert) to be sent after the
commitment message.
If the commitment message did constitute an alternative success
mechanism, then an attacker injecting an
EAP-Success message would be able to cause the peer to believe that
authentication
had succeeded even though it had actually failed (e.g. TLS alert sent
after the commitment message).
Given these issues, I believe the specification needs to answer
several questions:
1. What constitutes an "alternative success" indication in the EAP-TLS
1.3 protocol?
2. At what point should keys be pushed down to the lower layer?
3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?
4. What is the purpose of the commitment message?
Only question 3 looks straight forward to me: receipt of TLS Alert
messages should be considered an alternative failure mechanism,
although perhaps some caveats need to be applied to address the
injection attacks described in [1].
[1] EAP Vulnerabilities and Improvements, Extensible Authentication
Protocol Vulnerabilities and Improvements (sjsu.edu)
<https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431&context=etd_projects>
[2] An Analysis of the IEEE 802.1X Standard, An Initial Security
Analysis of the IEEE 802.1X Standard | Request PDF (researchgate.net)
<https://www.researchgate.net/publication/2562682_An_Initial_Security_Analysis_of_the_IEEE_8021X_Standard>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
