Subject: [Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

From: John Mattsson <[email-masked]>
Date: Sat, 6 Feb 2021 09:43:15 +0000

Hi,

Bernard brought up compability with RFC 4137 and the need for protected alternate indication of success in the context of EAP-TLS 1.3

https://mailarchive.ietf.org/arch/msg/emu/F-LcEX3UbAEX20Amk0xBBqfPQNQ/

I think we need to discuss this in a general EAP setting as this in not EAP-TLS specific at all but also related to all other EAP methods including draft-ietf-emu-rfc5448bis, draft-ietf-emu-aka-pfs, draft-ietf-emu-eap-noob, and draft-ingles-eap-edhoc.

The need for anprotected alternate indication of success in IEEE 802.1X is as described in [1]

  "lack of per-packet authenticity and integrity in IEEE 802.11 frames (data and management) has been a key contributor in many of the protocol's security problems."

  "due to a series of flaws in the composition of protocols that make up RSN".

Regarding solutions [1] states

  "there are currently no plans by the IEEE to add integrity protection to management frames"

  "Fortunatly, however, our attacks can easily be prevented through the addition of message authenticity to EAP"

To summarize IEEE 802.1X has some design flaws that will not be fixed. Any EAP method must have a protected alternate indication of success to be secure in IEEE 802.1X.

The attack seems pretty bad. Without a protected alternate indication of success an attacker can easily hijack the whole connection. I do not have a deep understanding of modern IEEE 802.1X, so I cannot say if anything has changed since 2002.

Looking at the other active documents in the EMU WG:

draft-ietf-emu-rfc5448bis
draft-ietf-emu-aka-pfs
draft-ietf-emu-eap-noob
and draft-ingles-eap-edhoc

None of them has a protected alternate indication of success and they would to my understanding be completely unsecure to use in IEEE 802.1X as it looked like in 2002.

Not having a protected alternate indication of success and pushing out keys before success is secure in general, otherwise TLS 1.3 itself would be insecure. I think all of these protocols would be secure when used in 3GPP 5G, but I think basically all EAP protocols want to function with IEEE 802.1X.

I think EMU need to verify that protected alternate indication of success is still needed in IEEE 802.1X. If it is I think draft-ietf-emu-rfc5448bis, draft-ietf-emu-aka-pfs, draft-ietf-emu-eap-noob, and draft-ingles-eap-edhoc need to be updated, or state that they cannot be used in IEEE 802.1X.

draft-ingles-eap-edhoc would be very easy to fix by just adding EDHOC message_4 which is desgined for use cases like this. EDHOC exported already derived keys from the client's second flight as recently discussed might be good to add to TLS 1.3.

[1] http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf

Cheers,
John

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Sun, 7 Feb 2021 02:08:09 +0100

Hi John, all:

First of all my apoligies if some thoughts in my e-mail have been already discussed. Please see inline.

> El 6 feb 2021, a las 10:43, John Mattsson <john.mattsson=[email-masked]> escribió:
> 
> Hi,
> 

If we take RFC 4137 as reference, altAccept and altReject are variables that are part of the interface defined from lower layer to EAP peer state machine (4.1.1. Variables (Lower Layer to Peer)). Therefore, I believe these variables are not related to the EAP method itself, unless I am missing something. These variables are more related with section 3.4 <https://tools.ietf.org/html/rfc3748#section-3.4>. Lower Layer Indications in RFC 3748. I mention this because these variables have been mentioned in relation to EAP-TLS. In any case, I think it would be important to clarify this because, as I said, I may be missing something.

Regarding eapKeyAvailable and eapKeyData, Figure 3 in RFC 4137 (https://tools.ietf.org/pdf/rfc4137.pdf <https://tools.ietf.org/pdf/rfc4137.pdf>) shows that the variable eapKeyAvailable is set to TRUE in the SUCCESS state, if key is available in eapKeyData. The SUCCESS state is reached in two cases: when an EAP Success is received or altAccept is set to TRUE. This variable altAccept is set by Lower Layer to EAP peer state machine. The same happens for altReject. However eapKeyData may have the key (see METHOD state) but the eapKeyAvailable variable will be FALSE until the EAP Success or altAccept is TRUE. It is completely certain that EAP Success is not protected and the message that enables the altAccept may be unprotected (e.g. first message of 4-way handshake in IEEE 802.11). 

Having said this, I think section 7.16 <https://tools.ietf.org/html/rfc3748#section-7.16>. Protected Result Indications in RFC 3748 is also relevant for the discussion.

In this sense, regarding draft-ingles-eap-edhoc please see below:

> draft-ingles-eap-edhoc would be very easy to fix by just adding EDHOC message_4 which is desgined for use cases like this.

EDHOC message_4 would help, however if you merely include this in the current flow in Figure 1 in draft-ingles-eap-edhoc  you will need an extra message_5 because EDHOC message_4 would be contained in a EAP Request so you need an EAP Response. To avoid this, my proposal is to change the roles (initiator, responder) so that the EDHOC exchanges would be as follows:

        Responder                                               Initiator
      +--------+                                               +-------+
      |   EAP  |                                               |  EAP  |
      |  Peer  |                                               | AuthN |
      +--------+                                               +-------+
        |                           EAP-Request/Identity        |
        | <---------------------------------------------------+ |
        |                                                       |
        |   EAP-Response/Identity (ID)                          |
        | +---------------------------------------------------> |
        |                                      EAP-Request/     |
        |                                EAP-Type=EAP-EDHOC     |
        |                                 (EDHOC message 1)     |
        | <---------------------------------------------------+ |
        |   EAP-Response/                                       |
        |   EAP-Type=EAP-EDHOC                                  |
        |   (EDHOC message 2)                                   |
        | +---------------------------------------------------> |
                                                              peer authenticated
        |                                      EAP-Request/     |
        |                                EAP-Type=EAP-EDHOC     |
        |                                  (EDHOC message 3)    |
        | <---------------------------------------------------+ |
    server authenticated
    eapKeyData = m.getKey()                                     |
        |                                                       |
        |   EAP-Response/                                       |
        |   EAP-Type=EAP-EDHOC                                  |
        |   (EDHOC message 4)                                   |
        | +---------------------------------------------------> |
        |                                                       | eapKeyData = m.getKey()
        |                                        EAP-Success    |
        | <---------------------------------------------------+ |
        +                                                       +

With EDHOC message 2 the peer is authenticated; with EDHOC message 3 the server can be authenticated by the peer and it is an protected indication to the peer that the server authenticated it. In that moment, the key can be pushed to eapKeyData in the EAP peer state machine (see METHOD state in RFC 4137 in Fig. 3). EDHOC message 4 is used for key confirmation and as an protected indication the peer has authenticated the server. The server after verifying EDHOC message 4 makes the key available to eapKeyData.

In this model, the EDHOC initiator is the server and the responder, the peer. If this is acceptable to solve the issue in EAP-EDHOC, we can update the document with this change. At least, it would cover the following text in 7.16 <https://tools.ietf.org/html/rfc3748#section-7.16>. Protected Result Indications in RFC 3748:

"In a method supporting result indications, a peer that has
   authenticated the server does not consider the authentication
   successful until it receives an indication that the server
   successfully authenticated it.  Similarly, a server that has
   successfully authenticated the peer does not consider the
   authentication successful until it receives an indication that the
   peer has authenticated the server.”

Any opinion?

Best Regards.

> EDHOC exported already derived keys from the client's second flight as recently discussed might be good to add to TLS 1.3.
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

------------------------------------------------------- Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Mohit Sethi M <[email-masked]>
Date: Sun, 7 Feb 2021 14:32:23 +0000

Hi all,

I am catching up on all the discussion of protected indication of success. I think it is important to note that protected indication of success can be exchanged in both directions (i.e. peer to server and server to peer). For example, RFC 3748 says:

   For example, within EAP-TLS [RFC2716<https://tools.ietf.org/html/rfc2716>], in the client authentication
   handshake, the server authenticates the peer, but does not receive a
   protected indication of whether the peer has authenticated it.  In
   contrast, the peer authenticates the server and is aware of whether
   the server has authenticated it.  In the session resumption
   handshake, the peer authenticates the server, but does not receive a
   protected indication of whether the server has authenticated it.  In
   this mode, the server authenticates the peer and is aware of whether
   the peer has authenticated it.

The discussion thus far has mostly focused on protected indication of success from the server to peer. I think in EAP-TLS 1.3 it is useful to have a protected indication of success from the server to the peer. Whether this is close_notify or one byte of application data can be discussed. The reason for having such a protected indication of success from the server to peer is because it also indicates that no more post handshake messages will be sent.

But I disagree that such protected indication of success is needed for all EAP methods. Note RFC 3748 says:

Result indications improve resilience to loss
   of Success and Failure packets when EAP is run over lower layers
   which do not support retransmission or synchronization of the
   authentication state.  In media such as IEEE 802.11, which provides
   for retransmission, as well as synchronization of authentication
   state via the 4-way handshake defined in [IEEE-802.11i<https://tools.ietf.org/html/rfc3748#ref-IEEE-802.11i>], additional
   resilience is typically of marginal benefit.

   Depending on the method and circumstances, result indications can be
   spoofable by an attacker.  A method is said to provide protected
   result indications if it supports result indications, as well as the
   "integrity protection" and "replay protection" claims.  A method
   supporting protected result indications MUST indicate which result
   indications are protected, and which are not.

   Protected result indications are not required to protect against
   rogue authenticators.  Within a mutually authenticating method,
   requiring that the server authenticate to the peer before the peer
   will accept a Success packet prevents an attacker from acting as a
   rogue authenticator.

Also note that spoofing an EAP-Success will still not force the peer to transition to the SUCCESS state. As shown in appendix A.1 of RFC 4137:

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

The peer cannot simply transition to SUCCESS state as the decision will still be set 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).

Additionally, the protected indication of success can help with synchronization of authentication result as noted in RFC 3748:

   While result indications may enable synchronization of the
   authentication result between the peer and server, this does not
   guarantee that the peer and authenticator will be synchronized

EAP-NOOB even models an attacker which can selectively drop the last message to cause a synchronization failure and has a mechanism to recover, see: https://tools.ietf.org/html/draft-ietf-emu-eap-noob-03#section-6.7

Finally, as noted in RFC 3748:

   Success indications may be explicit or implicit.

So in some cases, receipt of a message from the server is sufficient to indicate that the peer was authenticated.

To summarize, we should have a protected success indication for EAP-TLS but there is no reason to panic and modify all other specifications.

--Mohit
On 2/6/21 11:43 AM, John Mattsson wrote:

Hi,

Cheers,
John

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu

---

From: Jari Arkko <[email-masked]>
Date: Mon, 8 Feb 2021 19:06:13 +0200

John,

This may be a side note in the TLS discussion, but just looked at the below list:

> […]
> None of them has a protected alternate indication of success […]

And it seems to me that RFC 4187 (EAP-AKA) does have protected result indicators (see Section 12.8). RFC 5448 (EAP-AKA’) is a diff to EAP-AKA, and it doesn’t add or remove of any of that. RFC5448bis even has a table (Section 3.5) that shows when AT_RESULT_IND, AT_NOTIFICATION, AT_ENCR_DATA, etc and EAP-Request/Response/AKA-Notification can be used. That table matches my understanding of RFC 4187 result indicators usage. I also checked an open source implementation and it seemed to be doing these functions.

As for the PFS extension, that shouldn’t remove any of the underlying features either.

(But I could easily have misunderstood or forgotten something. Happy to learn or fix things if so.)

Jari

---

From: John Mattsson <[email-masked]>
Date: Mon, 8 Feb 2021 17:37:34 +0000

Thanks,

Good to know that RFC 5448 (EAP-AKA’) and aka-pfs have protected result indicators. I missed that RFC 5448 gets this from RFC 4187.

John

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, 8 February 2021 at 18:07
To: John Mattsson <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

John,

Jari