Hi,
Bernard Aboba wrote:
> 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
> The issue in the EAP-TLS 1.3 specification is that the interlock with these
> variables is not defined
It is definitely true that the EAP TLS 1.3 specification does not at all define
how EAP-TLS 1.3 interlock with these variables, neither does RFC 5216. Might be
that this is needed for TLS 1.3 but was not needed for earlier versions of TLS.
I think this has not been discussed at all before. I will make new issue on
GitHub.
> 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?
These are things that to my knowledge are not in RFC 5216. If they are they
would apply to EAP-TLS 1.3 as well. It would be good if you could further
explain if these are things that:
- Where missing from RFC 5216 and should be added now for all versions of TLS
- Are in RFC 5216 but are not applicable to TLS 1.3 due to massive changes in
the protocol and therefor need to be rewritten in the draft.
- Where not needed in RFC 5216 for earlier versions of TLS but are needed for
TLS 1.3 due to the changes in the protocol.
> 4. What is the purpose of the commitment message?
4. was something I thought was clear. The -13 version states that “The EAP-TLS
server commits to not send any more handshake messages”. This was according to
my memory exactly what was requested from the implementors. In the last weeks
discussion, the commitment message has been given a lot of different
interpretations that are not coming from the draft. The meaning of and
requirements for the -13 commitment message now seems quite unclear.
Cheers,
John
From: Emu <emu-boun...@ietf.org> on behalf of Bernard Aboba
<bernard.ab...@gmail.com>
Date: Tuesday, 2 February 2021 at 16:25
To: "emu@ietf.org" <emu@ietf.org>
Subject: [Emu] Underspecification of EAP-TLS 1.3 State Machine
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
