Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Mohit Sethi M]

Bernard:

RFC 4137 says:

   altAccept (boolean)

  Alternate indication of success, as described in 
[RFC3748].

   altReject (boolean)

  Alternate indication of failure, as described in 
[RFC3748].

Is it referring to section 7.16 of RFC 3748:

7.16.  Protected Result Indications

or section 3.4 of RFC 3748:

3.4.  Lower Layer Indications

--Mohit
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Bernard Aboba]

Mohit --

The authors of RFC 4137 were among the group (Bill Arbaugh's team and UMD)
that wrote paper [2].  The goal of that RFC was to address the security
vulnerabilities they found, which were considered serious enough to block
the deployment of EAP and IEEE 802.11.  As a result, RFC 4137 is widely
supported by EAP implementations, and bugs (if found) would be considered a
security vulnerability with a fix expected.

On Sun, Feb 7, 2021 at 9:32 PM Mohit Sethi M 
wrote:

> Hi all,
>
> I have now read both the papers. I am not sure the attacks in [2] are
> anymore possible:
>
> - The first attack described in section 4.1.1 shows that an EAP-Success
> leads to an unconditional transition to the Authenticated state
> irrespective of the current state. However, I am not sure this is the case
> anymore as RFC 4137 (https://tools.ietf.org/html/rfc4137#appendix-A.1)
> now says :
>
>  |+--
>  |  rxSuccess &&  |
>  |  (reqId == lastId) &&  |   SUCCESS
>  |   (decision != FAIL)   |
>  |+--
>
> The peer cannot simply transition to SUCCESS state as the decision is
> initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only
> after the peer decides that the server has sufficiently been authenticated
> (for EAP methods with mutual authentication).
>
> - The second attack described in section 4.2 relies on the adversary
> sending a disassociate management frame and then uses the MAC address of
> the authenticated supplicant to gain network access. This again should not
> work as a) 802.11w-2009 protects disassociate management frame, and b)
> EAP-Success is followed by 4-way handshake after which there is per packet
> authenticity and integrity (with Key Confirmation Key). The attacker cannot
> gain network access without knowing the PMK (derived from the MSK) and
> performing the 4-way handshake.
>
> The attacks in [1] are not specific to EAP. The attacks relate to Denial
> of Service (DoS) by injecting spoofed alerts in TLS. John has suggested the
> following text for the draft (which I think is sufficient):
>
> Protected TLS Error alerts are protected failure result indications and
> enables the EAP-TLS peer and EAP-TLS server to determine that the failure
> result was not spoofed by an attacker. Protected failure result indications
> provide integrity protection and replay but MAY be unauthenticated.
> Protected failure result does not significantly improve availability as TLS
> 1.3 treats most malformed data as a fatal error.
>
> --Mohit
>
> [1] Extensible Authentication Protocol Vulnerabilities and Improvements :
> https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431=etd_projects
> [2] An Initial Security Analysis of the IEEE 802.1X Standard :
> http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf
> On 2/4/21 2:18 PM, John Mattsson wrote:
>
> 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 

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Bernard Aboba]

John said:


"Based on your comments it seems like protected success indication is not
needed in IEEE 802 for security reasons."


[BA] As described in RFC 4137, protected success indications prevent
attacks involving injection of unprotected EAP-Failure indications, as well
as enabling key synchronization.  So yes, they do serve a purpose.


Would also be good to conclude that other methods do not need an alternate
success indication.


[BA] That would not be good, because it would be an incorrect conclusion.



Note that RFC 4137 is informal and not mandatory to follow.


[BA] Every EAP implementation I am aware of supports RFC 4137.  It was
specifically developed to address security vulnerabilities that were
considered serious enough to block deployment of EAP.  So you can say it is
"informal", "not required", etc. but in practice it is implemented and
necessary.


Similarly a implementation can ignore the alternative success indication
unless EAP-TLS 1.3 makes it mandatory.


[BA] Implementers are going to support alt success and alt failure
indications, as they indicated on the mailing list, because those
indications have been supported by EAP-TLS and other secure EAP methods for
more than a decade. It's not productive to re-introduce security
vulnerabilities into EAP after years of work to remove them.

On Sun, Feb 7, 2021 at 10:39 PM John Mattsson 
wrote:

> Thanks Mohit,
>
>
>
> Based on your comments it seems like protected success indication is not
> needed in IEEE 802 for security reasons. Would be good with more feedback
> on this. EAP-TLS 1.3 might get a protected success indication anyway, but
> the draft should have a few sentences about what the alternate success
> indication is good for. Would also be good to conclude that other methods
> do not need an alternate success indication. Seems like e.g. RFC 5448
> removed the optional result indications from RFC 4187, probably after an
> agreement that they were not needed.
>
>
>
> Note that RFC 4137 is informal and not mandatory to follow. Similarly a
> implementation can ignore the alternative success indication unless EAP-TLS
> 1.3 makes it mandatory. In RFC 5216 it is to my understanding up to the
> implementation if it wants to use server Finished as a alternate success
> indication.
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Mohit Sethi M 
> *Date: *Monday, 8 February 2021 at 06:33
> *To: *John Mattsson , Bernard Aboba <
> bernard.ab...@gmail.com>, "emu@ietf.org" , "t...@ietf.org" <
> t...@ietf.org>
> *Subject: *Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
>
>
>
> Hi all,
>
> I have now read both the papers. I am not sure the attacks in [2] are
> anymore possible:
>
> - The first attack described in section 4.1.1 shows that an EAP-Success
> leads to an unconditional transition to the Authenticated state
> irrespective of the current state. However, I am not sure this is the case
> anymore as RFC 4137 (https://tools.ietf.org/html/rfc4137#appendix-A.1)
> now says :
>
>  |+--
>
>  |  rxSuccess &&  |
>
>  |  (reqId == lastId) &&  |   SUCCESS
>
>  |   (decision != FAIL)   |
>
>  |+--
>
> The peer cannot simply transition to SUCCESS state as the decision is
> initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only
> after the peer decides that the server has sufficiently been authenticated
> (for EAP methods with mutual authentication).
>
> - The second attack described in section 4.2 relies on the adversary
> sending a disassociate management frame and then uses the MAC address of
> the authenticated supplicant to gain network access. This again should not
> work as a) 802.11w-2009 protects disassociate management frame, and b)
> EAP-Success is followed by 4-way handshake after which there is per packet
> authenticity and integrity (with Key Confirmation Key). The attacker cannot
> gain network access without knowing the PMK (derived from the MSK) and
> performing the 4-way handshake.
>
> The attacks in [1] are not specific to EAP. The attacks relate to Denial
> of Service (DoS) by injecting spoofed alerts in TLS. John has suggested the
> following text for the draft (which I think is sufficient):
>
> Protected TLS Error alerts are protected failure result indications and
> enables the EAP-TLS peer and EAP-TLS server to determine that the failure
> result was not spoofed by an attacker. Protected failure result indications
> provide integrity protection and replay but MAY 

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[John Mattsson]

Thanks Mohit,

Based on your comments it seems like protected success indication is not needed 
in IEEE 802 for security reasons. Would be good with more feedback on this. 
EAP-TLS 1.3 might get a protected success indication anyway, but the draft 
should have a few sentences about what the alternate success indication is good 
for. Would also be good to conclude that other methods do not need an alternate 
success indication. Seems like e.g. RFC 5448 removed the optional result 
indications from RFC 4187, probably after an agreement that they were not 
needed.

Note that RFC 4137 is informal and not mandatory to follow. Similarly a 
implementation can ignore the alternative success indication unless EAP-TLS 1.3 
makes it mandatory. In RFC 5216 it is to my understanding up to the 
implementation if it wants to use server Finished as a alternate success 
indication.

Cheers,
John

From: Mohit Sethi M 
Date: Monday, 8 February 2021 at 06:33
To: John Mattsson , Bernard Aboba 
, "emu@ietf.org" , "t...@ietf.org" 

Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine


Hi all,

I have now read both the papers. I am not sure the attacks in [2] are anymore 
possible:

- The first attack described in section 4.1.1 shows that an EAP-Success leads 
to an unconditional transition to the Authenticated state irrespective of the 
current state. However, I am not sure this is the case anymore as RFC 4137 
(https://tools.ietf.org/html/rfc4137#appendix-A.1) now says :

 |+--

 |  rxSuccess &&  |

 |  (reqId == lastId) &&  |   SUCCESS

 |   (decision != FAIL)   |

 |+--
The peer cannot simply transition to SUCCESS state as the decision is 
initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only after 
the peer decides that the server has sufficiently been authenticated (for EAP 
methods with mutual authentication).

- The second attack described in section 4.2 relies on the adversary sending a 
disassociate management frame and then uses the MAC address of the 
authenticated supplicant to gain network access. This again should not work as 
a) 802.11w-2009 protects disassociate management frame, and b) EAP-Success is 
followed by 4-way handshake after which there is per packet authenticity and 
integrity (with Key Confirmation Key). The attacker cannot gain network access 
without knowing the PMK (derived from the MSK) and performing the 4-way 
handshake.

The attacks in [1] are not specific to EAP. The attacks relate to Denial of 
Service (DoS) by injecting spoofed alerts in TLS. John has suggested the 
following text for the draft (which I think is sufficient):
Protected TLS Error alerts are protected failure result indications and enables 
the EAP-TLS peer and EAP-TLS server to determine that the failure result was 
not spoofed by an attacker. Protected failure result indications provide 
integrity protection and replay but MAY be unauthenticated. Protected failure 
result does not significantly improve availability as TLS 1.3 treats most 
malformed data as a fatal error.
--Mohit

[1] Extensible Authentication Protocol Vulnerabilities and Improvements : 
https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431=etd_projects
[2] An Initial Security Analysis of the IEEE 802.1X Standard : 
http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf
On 2/4/21 2:18 PM, John Mattsson wrote:
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 clo

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Mohit Sethi M]

Hi all,

I have now read both the papers. I am not sure the attacks in [2] are anymore 
possible:

- The first attack described in section 4.1.1 shows that an EAP-Success leads 
to an unconditional transition to the Authenticated state irrespective of the 
current state. However, I am not sure this is the case anymore as RFC 4137 
(https://tools.ietf.org/html/rfc4137#appendix-A.1) now says :

 |+--
 |  rxSuccess &&  |
 |  (reqId == lastId) &&  |   SUCCESS
 |   (decision != FAIL)   |
 |+--

The peer cannot simply transition to SUCCESS state as the decision is 
initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only after 
the peer decides that the server has sufficiently been authenticated (for EAP 
methods with mutual authentication).

- The second attack described in section 4.2 relies on the adversary sending a 
disassociate management frame and then uses the MAC address of the 
authenticated supplicant to gain network access. This again should not work as 
a) 802.11w-2009 protects disassociate management frame, and b) EAP-Success is 
followed by 4-way handshake after which there is per packet authenticity and 
integrity (with Key Confirmation Key). The attacker cannot gain network access 
without knowing the PMK (derived from the MSK) and performing the 4-way 
handshake.

The attacks in [1] are not specific to EAP. The attacks relate to Denial of 
Service (DoS) by injecting spoofed alerts in TLS. John has suggested the 
following text for the draft (which I think is sufficient):

Protected TLS Error alerts are protected failure result indications and enables 
the EAP-TLS peer and EAP-TLS server to determine that the failure result was 
not spoofed by an attacker. Protected failure result indications provide 
integrity protection and replay but MAY be unauthenticated. Protected failure 
result does not significantly improve availability as TLS 1.3 treats most 
malformed data as a fatal error.
--Mohit

[1] Extensible Authentication Protocol Vulnerabilities and Improvements : 
https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431=etd_projects
[2] An Initial Security Analysis of the IEEE 802.1X Standard : 
http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf

On 2/4/21 2:18 PM, John Mattsson wrote:
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 

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Alan DeKok]

On Feb 4, 2021, at 9:22 AM, John Mattsson 
 wrote:
> 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.

  Yes.  Unfortunately 5216 didn't pay enough attention to 4137.  That happens.

> 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.

  I  think the TLS libraries rely on the application to initiate close_notify.

> 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.

  Yes.

> 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.

   Yes.  However, I don't think that the close_notify can be sent before 
verifying the client cert, because IIRC, that closes the TLS connection (server 
side), and prevents it from sending TLS alerts.

> 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.

  Yes.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Bernard Aboba]

John said:

"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."

[BA]  There is a distinction between when keys are available on the EAP
server,  and when they are transmitted by the EAP Server to the
authenticator (after an EAP-Success is sent).  Also, there is a distinction
between when the EAP peer derives the keys and when they are to be pushed
down to the lower layer (this should only happen after an alternative
success indication is received). The state machine is more driven by the
transmission/push-down of keys than by their mere derivation.

I'll let the implementers comment on the practicality of a close_notify as
an alternative success indication, as opposed to other potential solutions.





I'll let the implementers comment on the practicality of what you are
proposing.

On Thu, Feb 4, 2021 at 3:14 PM John Mattsson 
wrote:

> 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 
> *Date: *Thursday, 4 February 2021 at 15:22
> *To: *Bernard Aboba , "emu@ietf.org" <
> emu@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

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[John Mattsson]

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 
Date: Thursday, 4 February 2021 at 15:22
To: Bernard Aboba , "emu@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 
Date: Thursday, 4 February 2021 at 13:18
To: Bernard Aboba , "emu@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-pat

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[John Mattsson]

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 
Date: Thursday, 4 February 2021 at 13:18
To: Bernard Aboba , "emu@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 i

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[John Mattsson]

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  on behalf of Bernard Aboba 

Date: Tuesday, 2 February 2021 at 16:25
To: "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].



   altReject (boolean)



  Alternate indication of failure, as described in 
[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].



   eapKeyAvailable (boolean)



  Set to TRUE in the SUCCESS state if 

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Alan DeKok]

On Feb 3, 2021, at 1:51 PM, Michael Richardson  wrote:
> My understanding is that:
>  1) the TLS Finish message can now occur prior to the client certificate
> even being transmitted, let alone validated.
> This is a feature in TLS 1.3 that lets application data in the
> typical browser->http server occur very early.
> 
>  2) As such, it is possible to run the TLS-Exporter function prior to
> actually having authenticated the client.
> This is part of the TLS 1.3 changes that essentially permit either
> end to (re-)authenticate at any point in the protocol.
> 
>  3) The EAP-Success message is not authenticated in any way.

  Yes.

> So it seems to be that:
> 
> a) The EAP-Success is meaningless.  The client needs to process it, but
>   it should not affect the state machine at all!

  It really seems so.  The EAP-Success is largely a signal to the Access point 
/ NAS / etc. that EAP has succeeded.  This signal needs to be independent of 
EAP type, so it's just a 4 byte "Success" packet.

> b) Success means being able to use the derived keys.
>   The keys won't be installed by the AAA server into the authenticator
>   until it has performed appropriate validation of the client.
>   (e.g, received and validated the client certificate)

  The key here is that the AAA server *can* define the keys earlier.  We may 
want to update the key derivation, so that the keys are derived from the client 
/ server certificates, too.

> c) More important than EAP-Success, is legitimate failure.   They need to be
>   unforgeable by an attacker.   Success is easy to determine, and
>   progress is easy to move forward with.  What breaks forward motion are
>   failure messages.  They need to be properly authenticated.

  RFC 8446 Section E.1 says:

   As soon as the client and the server have exchanged enough
   information to establish shared keys, the remainder of the handshake
   is encrypted, thus providing protection against passive attackers,

  So the TLS Alert messages would seem to be encrypted.  It would be good to 
get clarification on this.  If true, it's one less thing that we have to worry 
about.

  If the TLS alert messages are encrypted, then they can't be forged.  A 
malicious actor could forge EAP-Failure, but RFC 3748 Section 7.16 says that 
peers should ignore unexpected failures:

   ... a peer silently discards a Failure packet
   received at a point where the method does not explicitly permit this
   to be sent.  For example, a method providing its own error messages
   might require the peer to receive an error message prior to accepting
   a Failure packet.

> While EAP-TLS does not really do anything with the resulting TLS channel
> afterwards, there are some protocols like EAP-TEAP (and BRSKI-TEAP), that
> would like to use the channel afterwards.  So anything learnt in EAP-TLS 1.3
> will get repeated.

  Yes.  We do need to ensure that whatever is done here will work for all other 
TLS-based EAP methods, for both the "full authentication", and the "resumption" 
exchanges.

> My instinct is that the best thing would be to have a TLS-level message which
> EAP-TLS 1.3 should define.  This is the real success or failure message.  TLS
> libraries would have to cope.

  I'm not sure that changing TLS is appropriate here.  But I can see how it 
would be useful.

  The "hacky" way to add signalling to EAP-TLS is to just send application data 
inside of the tunnel.  The (eventual) follow-on question is then how that 
affects other TLS-based EAP methods.

> The application data, byte, vs zero-length data discussion seems to be
> basically dancing around this.  TLS 1.3 is too flexible, and we can't either
> constrain the TLS 1.3 state machine, nor can we depend upon it anymore the
> way that one could with 1.2.

  Yes.

  It looks now like the main issue is getting an *authenticated* success from 
the EAP server to the EAP peer.  Neither CloseNotify, not the Commitment 
message are sufficient for that purpose.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Michael Richardson]

I haven't been able to follow all of thread on the impedance mismatch between
EAP and TLS, which the EAP-TLS specification is intended to resolve.
(I did talk on the phone with Alan yesterday, and he recapped some issues for
me.   My other qualification is that I implemented EAP-SIM 20 years ago, and
I did some EAP over IKEv1 work at one point)

My understanding is that:
  1) the TLS Finish message can now occur prior to the client certificate
 even being transmitted, let alone validated.
 This is a feature in TLS 1.3 that lets application data in the
 typical browser->http server occur very early.

  2) As such, it is possible to run the TLS-Exporter function prior to
 actually having authenticated the client.
 This is part of the TLS 1.3 changes that essentially permit either
 end to (re-)authenticate at any point in the protocol.

  3) The EAP-Success message is not authenticated in any way.

So it seems to be that:

a) The EAP-Success is meaningless.  The client needs to process it, but
   it should not affect the state machine at all!

b) Success means being able to use the derived keys.
   The keys won't be installed by the AAA server into the authenticator
   until it has performed appropriate validation of the client.
   (e.g, received and validated the client certificate)

c) More important than EAP-Success, is legitimate failure.   They need to be
   unforgeable by an attacker.   Success is easy to determine, and
   progress is easy to move forward with.  What breaks forward motion are
   failure messages.  They need to be properly authenticated.

While EAP-TLS does not really do anything with the resulting TLS channel
afterwards, there are some protocols like EAP-TEAP (and BRSKI-TEAP), that
would like to use the channel afterwards.  So anything learnt in EAP-TLS 1.3
will get repeated.

My instinct is that the best thing would be to have a TLS-level message which
EAP-TLS 1.3 should define.  This is the real success or failure message.  TLS
libraries would have to cope.

The application data, byte, vs zero-length data discussion seems to be
basically dancing around this.  TLS 1.3 is too flexible, and we can't either
constrain the TLS 1.3 state machine, nor can we depend upon it anymore the
way that one could with 1.2.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Alan DeKok]

On Feb 3, 2021, at 8:32 AM, John Mattsson 
 wrote:
> I seriously don't know where you got all of the above from. I only summarized 
> the earlier discussion. I did not state any opinions.

  I'm asking you as author to understand, explain, and defend the draft that 
you wrote.  The issue is *exactly* that you didn't state opinions.

> I think the group needs to discuss if -13 or -14 can be a basis for 
> publishing or if we need substantial changes. The version the working group 
> wants to publish also needs to pass IESG, that is a fact. The suggestion that 
> EAP-TLS 1.3 should document detailed interaction with the informal EAP state 
> machine is very new.

  Jouni Malinen brought up the question of RFC 4137 2.5 years ago, in the 
message you referred to recently.  This isn't new.

> Regarding the EAP/EAP-TLS/TLS 1.3 interaction I don't think there are any 
> really good short term solution. The chosen mechanism will likely have 
> significant drawbacks and tradeoffs.

  Such as?

> My personal opinion is that the application data commitment message seems to 
> be a bit less problematic then close_notify. None of them are an "alternative 
> success", if that is what is needed, I don't think any of them work.

  Why?

  Perhaps the draft could be updated to *explain* these issues?  I'm still 
rather surprised that with open issues, the suggestion was that the "best way 
forward" was just to publish the draft.  It's simply not.

> The current objective status (without defending or offending anybody) is that 
> if the WG cannot agree on adding clarifications and smaller updated to -14, 
> EAP-TLS 1.3 will likely be significantly delayed. The comments on -14 in the 
> WG so far is that it should not progress and that decisions need to wait 
> until IETF 110 hackaton and EMU meeting. Delaying may be the right option, 
> but the WG should be aware of this. A couple of weeks ago, I understood you 
> position as moving forward with either version was the most important goal. 

  No.  I am never of the opinion that the most important goal is to publish.

  While timeliness is important, if we don't *understand* what we're 
publishing, then that is a total show-stopper.  We have to hold off publishing 
"something" until we understand exactly what we're doing.

  While I mostly like -13, it's not clear to me what, if any, utility the 
commitment message has.  When I ask "what does it do, and why", it's not 
helpful to answer "we added it years ago".

  If the draft cannot explain the pros and cons of it's choices, then the draft 
should be updated to do that.  If it's not clear *why* content is in the draft, 
then we should figure it out.  That's why I'm asking questions, and why I would 
very much appreciate answers to those questions.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[John Mattsson]

 Alan DeKok wrote:

>Does that mean all open issues have been addressed and resolved?
>
>The current suggestion from Eric is to *not* use application data, but to use 
>>CloseNotify instead.  Does this mean the earlier discussion was wrong, or is 
>the >current suggestion wrong?  Are we allowed to dig into reasons *why* we're 
>doing >this?
>
>I'm a little taken aback at the appeal to authority, and the opinion that the 
>>"best way forward" is to just publish a document we don't understand.
>
>I'll also note that you're defending the *process*.  You're not defending the 
>>*content* of the draft.  So do you stand behind it?  i.e. do *you* have 
>reasons >why this behaviour is necessary?  The above summary from 2.5 years 
>ago discusses >*what* was decided.  The draft (and the summary) still makes no 
>mention of *why* >it's done, or why it's useful.
>
>The purpose of the draft is not to just publish "something".  The purpose of 
>the >draft is to publish a clear, secure, spec for EAP-TLS 1.3.  The current 
>discussion >does not give me confidence that we're making progress.


I seriously don't know where you got all of the above from. I only summarized 
the earlier discussion. I did not state any opinions.

I think the group needs to discuss if -13 or -14 can be a basis for publishing 
or if we need substantial changes. The version the working group wants to 
publish also needs to pass IESG, that is a fact. The suggestion that EAP-TLS 
1.3 should document detailed interaction with the informal EAP state machine is 
very new. This is something RFC 5216 leaves completely to the implementor, but 
as it is important to security I think it might be good idea to do.

Regarding the EAP/EAP-TLS/TLS 1.3 interaction I don't think there are any 
really good short term solution. The chosen mechanism will likely have 
significant drawbacks and tradeoffs. My personal opinion is that the 
application data commitment message seems to be a bit less problematic then 
close_notify. None of them are an "alternative success", if that is what is 
needed, I don't think any of them work.

The current objective status (without defending or offending anybody) is that 
if the WG cannot agree on adding clarifications and smaller updated to -14, 
EAP-TLS 1.3 will likely be significantly delayed. The comments on -14 in the WG 
so far is that it should not progress and that decisions need to wait until 
IETF 110 hackaton and EMU meeting. Delaying may be the right option, but the WG 
should be aware of this. A couple of weeks ago, I understood you position as 
moving forward with either version was the most important goal. 

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Alan DeKok]

On Feb 3, 2021, at 5:26 AM, John Mattsson 
 wrote:
> At the same meeting it was also ruled out to use the Reserved bits in EAP-TLS 
> header and to make EAP-Success carry payload. Latency and security was 
> discussed a lot with Bernard keeping the security high and Jouni expressing 
> on the mailing list before the meeting that he wanted to cut even more 
> roundtrips from the message flow.
> 
> According to the minutes it seems like Jim suggested the use of application 
> data and Eric suggested the interpretation to make this mean no more 
> handshake messages. This was added to the draft and everybody was happy with 
> that for 2.5 years. While individual persons cannot represent the TLS WG, 
> there was a large amount of senior TLS people present and active in the 
> discussion.

  Does that mean all open issues have been addressed and resolved?

  The current suggestion from Eric is to *not* use application data, but to use 
CloseNotify instead.  Does this mean the earlier discussion was wrong, or is 
the current suggestion wrong?  Are we allowed to dig into reasons *why* we're 
doing this?

  I'm a little taken aback at the appeal to authority, and the opinion that the 
"best way forward" is to just publish a document we don't understand.

  I'll also note that you're defending the *process*.  You're not defending the 
*content* of the draft.  So do you stand behind it?  i.e. do *you* have reasons 
why this behaviour is necessary?  The above summary from 2.5 years ago 
discusses *what* was decided.  The draft (and the summary) still makes no 
mention of *why* it's done, or why it's useful.

  The purpose of the draft is not to just publish "something".  The purpose of 
the draft is to publish a clear, secure, spec for EAP-TLS 1.3.  The current 
discussion does not give me confidence that we're making progress

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[John Mattsson]

Hi,

Maybe not so important to figure out who suggested what, but I think the whole 
discussion took place at IETF 102. 

https://datatracker.ietf.org/meeting/102/materials/slides-102-emu-eap-tls-with-tls-13-00.pdf

https://datatracker.ietf.org/meeting/102/materials/minutes-102-emu-00

https://www.youtube.com/watch?v=Ez2Y4wK94Sk

At the same meeting it was also ruled out to use the Reserved bits in EAP-TLS 
header and to make EAP-Success carry payload. Latency and security was 
discussed a lot with Bernard keeping the security high and Jouni expressing on 
the mailing list before the meeting that he wanted to cut even more roundtrips 
from the message flow.

According to the minutes it seems like Jim suggested the use of application 
data and Eric suggested the interpretation to make this mean no more handshake 
messages. This was added to the draft and everybody was happy with that for 2.5 
years. While individual persons cannot represent the TLS WG, there was a large 
amount of senior TLS people present and active in the discussion.

-

John: Jouni implemented this draft and found the NewSessionTicket was 
inconvenient 

Darshak:  Point is well taken. We should not restrict NewSessionTicket. The 
server could signal with EAP that it will send other things.


Bernard: You are not changing EAP. EAP-Success can be spoofed. Understand 
exactly which state it is, not an EAP task but method specific. Reception of 
properly encrypted message should take precedence over EAP-Success. At every 
point, important to know if you are in continuing, success or failed state. It 
has nothing to do with EAP.

Jim Schaad: Have the server send an encrypted content message. Will add 
latency. 

Bernard: That's how EAP-TLS does currently with Finish message.

Darshak: Does sending this encrypted content message indicate that no more TLS 
messages will be sent. 

Jim: TLS content message (a record) to know when you are done and make 
transition. That takes the place of the TLS Finish message.

Hannes: Differenced to other EAP messages. Before there were clear definitions. 
What is finished actually? NewSessionTicket is still a handshake. Cram it in 
earlier in the exchange.

Darshak: Isn't the TLS server allowed to send NewSessionTicket later. Are you 
restricting it in EAP?

Eric: You want to know that there will be no more TLS messages? Profile TLS to 
say don't do this. None of the Post-Handshake messages are needed. 

John: Need more discussion on the mailing list. Could we use FLAG in EAP-TLS.
Bernard: If you use this and it determines cryptographic state, then you have 
just introduced a vulnerability. Don't do that. 

John: Piggyback Newsessionticket on the EAP-SUCCESS 
Bernard: Not a good idea.

-

Do close_notify even fulfill the requirements here. It cannot be spoofed, but 
it is a very strange alternative success message. It can also be sent by the 
server earlier to indicate failure for any reason

Cheers,
John

-Original Message-
From: John Mattsson 
Date: Wednesday, 3 February 2021 at 00:48
To: "emu@ietf.org" 
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

Alan wrote:

> wrote:
>> 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.
>
>  The text is in draft-mattsson-eap-tls13-02, but not in 
> draft-ietf-emu-eap->tls13-00.  The announcement message is here:
>
>https://mailarchive.ietf.org/arch/msg/emu/8Axkmgh_ZPCTwhvmRjVMvXGTKko/
>
>  Which doesn't mention the commitment message.  I can't find any other 
> >discussion about the commitment message on the archive.  That doesn't 
> >necessarily mean much, as the archive is difficult to search.
>
>  So it's not clear where that came from.

I Agree. The initial problem was brought up by Jouni who identified both the 
problem with the extra round-trip as well as the uncertainty in the EAP state 
machine.

https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/

The idea with the commitment message was suggested by Jim Schaad during IETF 
102 and then added in -01. The meaning of the commitment message was likely 
also discussed during that EMU session. I do not remember the exact 
discussions. It was likely not an implementor that suggested this definition. I 
mixed it up with Jouni raising the problem.

> 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.
>
> An in-progress draft is not an authoritative source of information.  The WG 
> >is discussing what the commitment message means, with an eye to making 

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Joseph Salowey]

On Tue, Feb 2, 2021 at 2:10 PM Alan DeKok  wrote:

> On Feb 2, 2021, at 4:42 PM, John Mattsson  40ericsson@dmarc.ietf.org> wrote:
> > 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.
>
>   The text is in draft-mattsson-eap-tls13-02, but not in
> draft-ietf-emu-eap-tls13-00.  The announcement message is here:
>
> https://mailarchive.ietf.org/arch/msg/emu/8Axkmgh_ZPCTwhvmRjVMvXGTKko/
>
>   Which doesn't mention the commitment message.  I can't find any other
> discussion about the commitment message on the archive.  That doesn't
> necessarily mean much, as the archive is difficult to search.
>
>   So it's not clear where that came from.
>
>
[Joe] I think this message from Jouni explains the original impetus to add
the commit message.
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/
What I'm gathering from this discussion is the state machine between TLS
1.3 and 1.2 is different enoguh that EAP-TLS implementations are going to
have to account for it.


> > 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.
>
>   An in-progress draft is not an authoritative source of information.  The
> WG is discussing what the commitment message means, with an eye to making
> recommendations for the draft, and implementors.
>
  Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[John Mattsson]

Alan wrote:

> wrote:
>> 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.
>
>  The text is in draft-mattsson-eap-tls13-02, but not in 
> draft-ietf-emu-eap->tls13-00.  The announcement message is here:
>
>https://mailarchive.ietf.org/arch/msg/emu/8Axkmgh_ZPCTwhvmRjVMvXGTKko/
>
>  Which doesn't mention the commitment message.  I can't find any other 
> >discussion about the commitment message on the archive.  That doesn't 
> >necessarily mean much, as the archive is difficult to search.
>
>  So it's not clear where that came from.

I Agree. The initial problem was brought up by Jouni who identified both the 
problem with the extra round-trip as well as the uncertainty in the EAP state 
machine.
 
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/

The idea with the commitment message was suggested by Jim Schaad during IETF 
102 and then added in -01. The meaning of the commitment message was likely 
also discussed during that EMU session. I do not remember the exact 
discussions. It was likely not an implementor that suggested this definition. I 
mixed it up with Jouni raising the problem.

> 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.
>
> An in-progress draft is not an authoritative source of information.  The WG 
> >is discussing what the commitment message means, with an eye to making 
> >recommendations for the draft, and implementors.

Of course not, but the exact same definition has been in the draft since -01 
without anybody question it before now. This made me think it was clear and 
widely accepted. That does not make it right and I have never said it is wrong 
to question that definition. I think we can agree that the meaning of the 
commitment message now seems unclear.

/John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[Alan DeKok]

On Feb 2, 2021, at 4:42 PM, John Mattsson 
 wrote:
> 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.

  The text is in draft-mattsson-eap-tls13-02, but not in 
draft-ietf-emu-eap-tls13-00.  The announcement message is here:

https://mailarchive.ietf.org/arch/msg/emu/8Axkmgh_ZPCTwhvmRjVMvXGTKko/

  Which doesn't mention the commitment message.  I can't find any other 
discussion about the commitment message on the archive.  That doesn't 
necessarily mean much, as the archive is difficult to search.

  So it's not clear where that came from.

> 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.

  An in-progress draft is not an authoritative source of information.  The WG 
is discussing what the commitment message means, with an eye to making 
recommendations for the draft, and implementors.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

[John Mattsson]

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  on behalf of Bernard Aboba 

Date: Tuesday, 2 February 2021 at 16:25
To: "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].



   altReject (boolean)



  Alternate indication of failure, as described in 
[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].



   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