Understanding 802.1X/EAP-TLS

[sylvain.benoit]

Hi,

I'm working on MACsec in an industrial context and after a first stage based on static keys (PSK for CAK) I need to automate the key management. This is why I try to understand MKA protocol and 802.1X. 

For availabity reason I have never used 802.1x at all !

In a basic scheme I've a PC (supplicant) want to reach a LAN through a switch (authenticator). The switch deals with a AAA server with informations provided by the PC to know if the connexion could be accepted (controlled port)

In my context I don't have such basic scheme : I use MACsec, switch-to-switch, ring (RSTP, MRP, REP, ...)

My understanding is today that the switch directly connected (s2) to the AAA server is the authenticator and others switches (s1,s3, s4) are supplicants (I'm not very sure of this first step).

At the end of 802.1X/EAP-TLS mutual authentication I should have a shared (unique) MSK only between 1 supplicant (e.g. s1) and the AAA server. By derivation the MSK will give the CAK. To communicate using MACsec at least 2 switches (in my example s1 and s3) must have the same CAK therefore the same MSK (as the kdf is the same)!

[s1] --------[s2]-------[AAA server]
  |                    |
  |       (ring)     |
  |                    |
[s3]---------[s4]
  |
  |
[OT device]

I should have missed something (about MSK I assume) ! Thus I need your help to clarify ...

Thank to the community, and @Tim.G 

Regards

[Rob Ingram]

@sylvain.benoit I think you meant to tag @Tim Glen who wrote some useful MACSec documents -  hopefully Tim will get a notification and can assist.

[M02@rt37]

Hello @sylvain.benoit 

Try to help with this step by step way.

Each switch to switch macsec link operates independently in terms of authentication and key derivation. During the 802.1X/EAP-TLS process, each supplicant (s1, s3, s4) authenticates with the AAA server (via s2 as the authenticator), and each authentication results in a unique MSK between the supplicant and the AAA server.

From this MSK, a CAK is derived for the specific link, and the MKA protocol uses the CAK to generate a unique SAK for encrypting traffic on that link...

For secure communication between two switches (s1 and s3) via macsec, both switches need to authenticate and establish their own CAKs with their respective peers in the ring. The encryption and key management are link-specific, meaning that s1 will not share its CAK (or MSK) with s3 unless they directly authenticate and form a MACsec link.

To enable end to end encryption across the ring, each pair of directly connected switches must independently establish macsec secured links. Therefore, the CAK is not globally shared among all switches, as it is derived per authenticated link.

--

French version needed ?

[sylvain.benoit]

Hi,

The French version is not necessary, as long as you accept my mistakes... but that means you are inferring that I am French from the text! it should be very .......... 

Thank for your answer. You confirm my first part about supplicant/authenticator. You confirm also my first understanding but there is still something that is not clear for me.

If s1 has a different MSK (I agree this is also my understanding of 802.1X/EAP-TLS) from s3 then CAK1 (CAK derived from the MSK of s1) will be different from CAK3 and KEK1/ICK1 will also be different from KEK3/ICK3 and (considering s1 as KS) the SAK can't be shared with s3. This confirms to me that MSK cannot be used to establish a CA, but that's not what I read, and that's the source of my questionning. There should be a solution, but I haven't figured it out yet.

My goal is to put an end to the use of PSK. When you write :

To enable end to end encryption across the ring, each pair of directly connected switches must independently establish macsec secured links.

---

Does this mean using PSK (CAK and CKN to define a CA) independently to the MSK ?

Regards,

[sylvain.benoit]

Hi,

What I understand from M02@rt37's answer :

Here, considering the link 1-3, S1 will work with KEK1 and S3 with KEK3. I don't understand how S3 will be able to decrypt the aes key sent by S1 and encrypted with KEK1 without knowing KEK1 ?

This should work because it is written in the standard, and you are probably right but I don't understand how. If someone can help me understand? There should be something shared between 2 switches to be able to derive the same keys (ICK, KEK) for me... but I can't identify what.

regards,

[M02@rt37]

Hello @elliot perrignon 

The key here is to understand this lies in the derivation and sharing of keys within the macsec key agreement process.

Each switch derives its own Master session key from the authentication process with the RADIUS server. From this master key, a Connectivity Association Key (CAK) is generated using a derivation function, and from the CAK, the Key encryption Key (KEK) and Integrity check key (ICK) are derived.

The crucial part is that for secure comunication between two switche (S1 and S3 on link 1-3), they must establish a common CAK. This ensures that both switches derive the same KEK and ICK, allowing them to securely exchange encryption keys and encrypted data.

Even though each switch has its own MSK, the CAK used on a specific link must be shared between the two participating switches.

The RADIUS server plays a central role in ensuring that both S1 and S3 receive compatible MSKs that allow them to derive the same CAK for their link. As a result, even though KEK1 and KEK3 are derived separately, on link 1-3, both S1 and S3 derive the same KEK from their shared CAK. This allows S3 to successfully decrypt the AES key sent by S1.

[elliot perrignon]

Hello M02@rt37 @Tim Glen, I am in the same misunderstanding. Does anyone have an answer ?

[zsgbrt4]

Yes, your understanding is mostly correct. In a switch-to-switch MACsec setup, the switch directly connected to the AAA server (s2) acts as the authenticator, while others (s1, s3, s4) are supplicants. However, MSK is typically unique to each supplicant-authenticator pair, so sharing the same CAK across multiple switches would require distributing the same MSK, which isn’t standard in typical 802.1X flows. YouCine

[sylvain.benoit]

Ok I worked to find my answer and since there is no answer here I deduce that the community does not master the topic.

[From what I understand]
The two switches perform an authN with the radius server and they each receive a different MSK. From this MSK, each of them will derive their MSK into a sort of ramdom token (called a temporary key). I don't know yet why they called it a key, which is why I use the more abstract word “token”.
This token is sent to the other switch using ASY cryptography, a bit like establishing a TLS tunnel.

The MSK is derived to protect it.

[From what I deduce]
They derive MSK because as it is a session ID it should be unpredictible ... But theorically any TRNG could be OK.

I update my own previous drawing as :