Hi Bernard,
802.11 is a very important use case for EAP-TLS so if an authenticated
alternate success indication is needed there, it absolutely needs to be
supported by EAP-TLS 1.3
I updated the EAP state machine chapter based on your comments.
---------------------------------------------------------------------------
2.5. EAP State Machines
This is a new section when compared to [RFC5216] and only applies to
TLS 1.3 (or higher). [RFC4137] offers a proposed state machine for
EAP
TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post-
Handshake messages use the handshake content type and can be sent
after the main handshake. Examples of Post-Handshake messages are
NewSessionTicket, which is used for resumption and KeyUpdate, which
is not useful and not expected in EAP-TLS. After sending TLS
Finished, the EAP-TLS server may send any number of Post-Handshake
messages in separate EAP-Requests.
To provide an authenticated success result indication and to decrease
the uncertainty for the EAP-TLS peer, the following procedure MUST be
followed:
When an EAP-TLS server has successfully processed the TLS client
Finished and sent its last handshake message (Finished or a Post-
Handshake), it commits to not sending any more handshake messages by
sending a TLS close_notify alert. The TLS close_notify alert is an
authenticated success result indication, as defined in [RFC3748].
After sending the TLS close_notify alert, the EAP-TLS server may only
send an EAP-Success. The EAP-TLS server MUST NOT send an TLS
close_notify alert before it has successfully processed the client
finished and sent its last handshake message.
Receipt of any TLS Error alert SHOULD be considered a failure result
indication, as defined in [RFC3748]. After sending or receiving a
TLS Error alert, the EAP-TLS server may only send an EAP-Failure.
The keying material becomes available in the EAP-TLS server after the
server Finished has been sent. The keying material becomes available
in the EAP-TLS peer after the server Finished has been received.
---------------------------------------------------------------------------
I used RFC 3748 terminology as RFC 4237 is an informal draft.
close_notify is now an authenticated success result indication (close_notify
could be replaced by TLS application data).
My undertstanding from RFC 4137 is that eapKeyAvailable and aaaEapKeyAvailable
seems
to be automatically set at success if eapKeyData and aaaEapKeyData are set.
if (eapKeyData != NONE)
eapKeyAvailable = TRUE
if (aaaEapKeyData != NONE)
aaaEapKeyAvailable = TRUE
I therefore only described when the "keying material becomes available" which
is the words used by RFC 4137 for eapKeyData and aaaEapKeyData.
Open question if Section 2.5 should say something about TLS 1.2.
Cheers,
John
From: John Mattsson <john.matts...@ericsson.com>
Date: Thursday, 4 February 2021 at 15:22
To: Bernard Aboba <bernard.ab...@gmail.com>, "emu@ietf.org" <emu@ietf.org>,
"t...@ietf.org" <t...@ietf.org>
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
I think the major decision for the EMU WG to make going forward is to agree if
EAP-TLS 1.3 MUST have an alternative success indication. RFC 5216 does not
discuss the EAP state machine at all, but in TLS 1.2 the server finished can be
used as an alternative success indication.
close_notify might be possible to turn into an alternative success indication
if the TLS implementation can be profiled to not send any close_notify by
itself. I don't know if there are any cases where an implementation would send
close_notify without the application telling it to.
If the wg agrees that an authenticated alternative success indication is needed
(this is to my understanding needed in e.g. 802.11) then the process would be
that the EAP-TLS server first process the second flight from the client, if
that verifies correctly, the server send application data commit message /
close_notify.
Introducing an authenticated alternative success indication would not require
any changes to the -14 message flows. In -13 the commitment message would have
to be sent in a later flight than server finished.
If a mandatory authenticated alternative success indication is introduced in
EAP-TLS 1.3, I do not think any future additions to TLS 1.3 would be needed for
EAP-TLS 1.3.
From: John Mattsson <john.matts...@ericsson.com>
Date: Thursday, 4 February 2021 at 13:18
To: Bernard Aboba <bernard.ab...@gmail.com>, "emu@ietf.org" <emu@ietf.org>,
"t...@ietf.org" <t...@ietf.org>
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
Hi Bernard,
I (re-)read the papers you send.
- "Extensible Authentication Protocol Vulnerabilities and Improvements
Improvements"
This paper talks attacks on availability by spoofing messages. It looks into
a small amount of ways where spoofed messages causes the TLS connection to
fail, especially it focus on alert messages.
TLS and EAP-TLS is trivial for an on-path attacker to shut down. Basically
any small error is fatal in TLS. Focusing on alert messages does not seem
correct. An attacker can e.g. at any time send a small record with length 2^15,
which causes TLS to terminate the connection. I think the only thing that can
be achieved without rewriting TLS is that availability attacks does not cause
long-term damage, i.e. the nodes can retry the handshake.
- "An Initial Security Analysis of the IEEE 802.1X Standard"
This paper discusses attacks on 801.11. The weaknesses described seems to
come from 802.11 / EAP interactions.
The discussions around IETF 102 was that the uncertainty (NewSessionTicket or
not) in TLS 1.3 was "inconvinient" and that it would be convient to get rid of
the uncertainty. Bernard then pointed out that any message changing the state
need to be authenticated to that it is not possible to spoof. I think that both
the application layer commit message as well as close_notify fulfill these old
requirements.
I think your analysis is correct.
1. What constitutes an "alternative success" indication in the EAP-TLS 1.3
protocol?
The -13 commitment message verifies that both sides are in possession of a
derived key. But the server finished already does that. As you state, the -13
commitment message is not an alternative success indication. I think it would
be easy to make it an alternative success indication be mandating that the
EAP-TLS server must only send it after verifying the client finished. I do not
think defining a new exporter is needed.
The -14 close_notify is also not an alternative success indication and can not
be made into one either.
If the requirement is that an alternative authenticated success indication is
needed. Then I think:
- We need to have an extra roundtrip.
- close_notify does not work and cannot be made to work
- Application data commit message could work as an alternative success
indication. TLS would have to be profiled so the alternative success is only
send be EAP-TLS server after client finished processed successfully.
2. At what point should keys be pushed down to the lower layer?
What is the exact requirement for eapKeyAvailable = TRUE to be set?
My understanding reading RFC 4137 (correct me if I am wrong) is that it is not
enough that the other party is authenticated, but that an alternative success
indication has been sent/received. If that is correct the EAP-TLS server would
set eapKeyAvailable = TRUE after sendign the alternative success indication and
the EAP-TLS client would set eapKeyAvailable = TRUE after receiving the
alternative success indication.
3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?
Yes, I agree, receipt of TLS Alert messages should be considered an alternative
failure mechanism.
4. What is the purpose of the commitment message?
The -01 to -13 purpose was to indicate in an authenticated way that the EAP-TLS
method would not continue and that only success or failure could follow.
If an alternative success indication is required. Which it seems to be
according to your mail. I think the alternative success indication would
replace the old commitment message.
I think
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
