MACSec MKA with 3 devices

[Mickael Chazaux]

On 20/07/2020 16:54, Mickael Chazaux wrote:
> On 16/07/2020 13:33, Mickael Chazaux wrote:
>> Hello,
>>
>> I am testing MACSec and MKA on a small lab network.
>>
>> Three devices are linked by a switch that let the 01:80:C2:00:00:03 DA pass.
>>
>> What I observe is that with only two devices on, MKA and MACSec work flawlessly. 
>> Key distribution happens and protected traffic is able to flow.
>>
> 
> Here are my findings after a day.
> 
> There are a few points I think are worth investigating : 
> 
>  - MKPDU should not be discarded as a whole when a parameter group encounters an error,
> 	This seems to break the election process.
>  - A fresh SAK should be generated when a new member joins, ie. when the key server adds 
> 	a new live peer. The call is made to ieee802_1x_kay_generate_sak, but seems to exit
> 	at the KaY: Life time has not elapsed since prior SAK distributed. This causes the
> 	key server to not install keys in the SA, breaking connectivity.
> 
> 
> With the changes below I have more reliable operation with 3 devices but not perfect. For
> some reason killing and restarting a wpa_supplicant quickly on one if the devices causes 
> no installation of the RXSA. 
> 
> I don't know about the security properties of the below patch : 
> 
> diff --git a/src/pae/ieee802_1x_kay.c b/src/pae/ieee802_1x_kay.c
> index a330d0cf4..fd8093cb5 100644
> --- a/src/pae/ieee802_1x_kay.c
> +++ b/src/pae/ieee802_1x_kay.c
> @@ -2108,7 +2108,7 @@ ieee802_1x_kay_generate_new_sak(struct ieee802_1x_mka_participant *participant)
>         if ((time(NULL) - kay->dist_time) < MKA_LIFE_TIME / 1000) {
>                 wpa_printf(MSG_ERROR,
>                            "KaY: Life time has not elapsed since prior SAK distributed");
> -               return -1;
> +               /*return -1;*/
>         }
>  
>         cs = &cipher_suite_tbl[kay->macsec_csindex];
> @@ -3269,7 +3269,7 @@ static int ieee802_1x_kay_decode_mkpdu(struct ieee802_1x_kay *kay,
>                                         wpa_printf(MSG_INFO,
>                                                    "KaY: Discarding Rx MKPDU: decode of parameter set type (%d) failed",
>                                                    body_type);
> -                                       return -1;
> +                                       /*return -1;*/
>                                 }
>  
>                                 /* Ideally DIST-SAK should be processed before
> @@ -3289,7 +3289,7 @@ static int ieee802_1x_kay_decode_mkpdu(struct ieee802_1x_kay *kay,
>                 }
>         }
>  
> -       if (bad_sak_use && !handled[MKA_DISTRIBUTED_SAK]) {
> +       if (0 && bad_sak_use && !handled[MKA_DISTRIBUTED_SAK]) {
>                 wpa_printf(MSG_INFO,
>                            "KaY: Discarding Rx MKPDU: decode of parameter set type (%d) failed",
>                            MKA_SAK_USE);
> 
> 
> 

More info : 

A reliable election of the key_server can be obtained by :
	- not changing the MI (the "0 && " in the patch) randomly,
	- and ignoring (eg commenting out) the if(peer->is_key_server) check 
	  in the election function.

This is because the election function is called only when there is a new
peer added or deleted to the live list, but it should be called also when 
the MKPDU KeyServer flag changes for a peer. Simple test : use three devices, 
let them elect one as the key server, and then kill the key server. The remaining
have KeyServer == 0 in their MKPDUs at the deletion of the key server from the 
live list, and each declares "I am the key server, because the other has KS=0". 
This is of course random. Sometimes one gets elected, sometimes they lock up.

Reliable installation of the SAK by the key server : 

ieee802_1x_kay_generate_new_sak should be aware of the rekeys caused by change of 
KS or live peer list. Disabling the return -1 as in the patch patches up the symptoms
but not the cause.

Processing of MKPDU messages : Some parameters blocks do not make sense if a peer list 
is not yet built. I think these blocks should be ignored and processing continue, to 
get to the information that makes sense and is useful. 

I am not sure on how to fix this properly. I am starting to think that heavy lifting 
may be required.

-- 
Mickael Chazaux
Software Engineer
Tel : (33) 476 042 006
Fax : (33) 476 042 001

ETIC TELECOM
13, Chemin du Vieux Chêne
38240 MEYLAN
Tel: 33 4 76 04 20 00
fax : 33 4 76 04 20 01