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
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
