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

[John Mattsson]

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: "jari.ar...@piuha.net" 
Date: Monday, 8 February 2021 at 18:07
To: John Mattsson 
Cc: EMU WG 
Subject: Re: [Emu] General EAP discussion of protected alternate indication of 
success, RFC 4137, and IEEE 802.1X

John,

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

> Looking at the other active documents in the EMU WG:
> 
> draft-ietf-emu-rfc5448bis
> draft-ietf-emu-aka-pfs
> […]
> 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


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

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

[Jari Arkko]

John,

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

> Looking at the other active documents in the EMU WG:
> 
> draft-ietf-emu-rfc5448bis
> draft-ietf-emu-aka-pfs
> […]
> 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

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

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

[Mohit Sethi M]

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], 
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], 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,

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

  

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

[Rafa Marin-Lopez]

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 
>  escribió:
> 
> 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/

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 
. 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 
) 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 
. Protected Result 
Indications in RFC 3748 is also relevant for the discussion.

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


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

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

[John Mattsson]

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


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