ieee802_1x_kay_deinit_receive_sc() frees the receive secure channel data,
but secy_delete_receive_sc() still needs it. Since these two functions
are always called sequentially, secy_delete_receive_sc() can be called
from ieee802_1x_kay_deinit_receive_sc() before rxsc is freed.
Fixes: 128f6a98b3 ("mka: Fix the order of operations in secure channel deletion")
Signed-off-by: Davide Caratti <davide.caratti@gmail.com>
The correct order of deleting a secure channel is to purge all the
secure associations in the channel before actually deleting the secure
channel.
Signed-off-by: Badrish Adiga H R <badrish.adigahr@gmail.com>
Issue: When 2 peers are running MACsec in PSK mode with CA
established, if the interface goes down and comes up after
time > 10 seconds, CA does not get re-established.
Root cause: This is because retry_count of both the peers
would have reached MAX_RETRY_CNT and stays idle for other to
respond. This is clear deadlock situation where peer A waits
for MKA packets from peer B to wake up and vice-versa.
Fix: If MACsec is running in PSK mode, we should send MKPDUs
forever for every 2 seconds.
Signed-off-by: Badrish Adiga H R <badrish.adigahr@gmail.com>
Issue:
------
The test setup has 2 peers running MACsec in PSK mode, Peer A with
MAC address higher than MAC Address of peer B. Test sequence is
1. Peer B starts with actor_priority 255
2. Peer A starts with priority 16, becomes key server.
3. Peer A stops..
4. Peer A restarts with priority 255, but because of the stale values
participant->is_key_server(=TRUE) and participant->is_elected(=TRUE)
it continues to remain as Key Server.
5. For peer B, key server election happens and since it has lower MAC
address as compared to MAC address of A, it becomes the key server.
Now we have 2 key servers in CA and is not correct.
Root-cause & fix:
-----------------
When number of live peers become 0, the flags such lrx, ltx, orx,
otx, etc. need to be cleared. In MACsec PSK mode, these stale values
create problems while re-establishing CA.
Signed-off-by: Badrish Adiga H R <badrish.adigahr@gmail.com>
API ieee802_1x_mka_decode_dist_sak_body() wrongly puts
participant->to_use_sak to TRUE, if Distributed SAK Parameter Set of
length 0 is received. In MACsec PSK mode, this stale incorrect value can
create problems while re-establishing CA. In MACsec PSK mode, CA goes
down if interface goes down and ideally we should be able to
re-establish the CA once interface comes up.
Signed-off-by: Badrish Adiga H R <badrish.adigahr@gmail.com>
This adds a new wpa_supplicant network profile parameter
mka_priority=0..255 to set the priority of the MKA Actor.
Signed-off-by: Badrish Adiga H R <badrish.adigahr@gmail.com>
This uses libnl3 to communicate with the macsec module available on
Linux. A recent enough version of libnl is needed for the macsec.h file
(which is not yet available in a formal libnl release at the time of
this commit).
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Previously, wpa_supplicant only supported hardcoded port == 1 in the
SCI, but users may want to choose a different port.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
So that the user can turn encryption on (MACsec provides
confidentiality+integrity) or off (MACsec provides integrity only). This
commit adds the configuration parameter while the actual behavior change
to disable encryption in the driver is handled in the following commit.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
The first peer may take a long time to come up. In PSK mode we are
basically in a p2p system, and we cannot know when a peer will join the
key exchange. Wait indefinitely, and let the administrator decide if
they want to abort.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
In commit a25e4efc9e ('mka: Add driver op
to get macsec capabilities') I added some code to check the driver's
capabilities. This commit has two problems:
- wrong enum type set in kay->macsec_confidentiality
- ignores that drivers could report MACSEC_CAP_NOT_IMPLEMENTED, in
which case the MKA would claim that MACsec is supported.
Fix this by interpreting MACSEC_CAP_NOT_IMPLEMENTED in the same way as a
DO_NOT_SECURE policy, and set the correct value in
kay->macsec_confidentiality.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
struct data_key already had a 'user' field for reference counting, but
it was basically unused.
Add an ieee802_1x_kay_use_data_key() function to take a reference on a
key, and use ieee802_1x_kay_deinit_data_key() to release the reference.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
This is specific to the macsec_qca driver. The core implementation
shouldn't care about this, and only deal with the complete secure
channel, and pass this down to the driver.
Drivers that have such limitations should take care of these in their
->create functions and throw an error.
Since the core MKA no longer saves the channel number, the macsec_qca
driver must be able to recover it. Add a map (which is just an array
since it's quite short) to match SCIs to channel numbers, and lookup
functions that will be called in every place where functions would get
the channel from the core code. Getting an available channel should be
part of channel creation, instead of being a preparation step.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
This also implements the macsec_get_capability for the macsec_qca
driver to maintain the existing behavior.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Assign cs in ieee802_1x_mka_decode_dist_sak_body and reuse it.
Cleanup of key allocation: ieee802_1x_kay_generate_new_sak() and
ieee802_1x_mka_decode_dist_sak_body() both allocate a struct key_conf,
fill it, and ask ieee802_1x_kay_init_data_key() to allocate and set up a
struct data_key. They also allocate multiple key buffers and copy the
same data around. Stop moving data from buffer to buffer, and just
allocate what we really need.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Instead of copying from kay to a temporary struct, and then from the
struct to the sm, just copy from kay to cp.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
This avoids unnecessary typecasting while still being able to compare
the value to CS_TABLE_SIZE without compiler warnings.
Signed-off-by: Jouni Malinen <j@w1.fi>
Share mka deletion implementation in ieee802_1x_participant_timer() for
the cak_life and mka_life expiration cases.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
This takes care of priority comparison followed by MAC address
comparison if the priorities are identical.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
to_use_sak is a Boolean variable, so there is no need for an if
statement to figure out whether to return TRUE or FALSE.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Use for loop to remove unnecessary goto use and similar cleanup to
simplify the loops in ieee802_1x_mka_i_in_peerlist(),
ieee802_1x_mka_decode_live_peer_body(), and
ieee802_1x_kay_decode_mkpdu().
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Each loop iteration resets body_peer in the beginning, so there is no
need to increment this pointer in the end.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Add ieee802_1x_kay_get_potential_peer() similarly to the previously used
ieee802_1x_kay_get_live_peer() and use these helper functions more
consistently to avoid multiple implementations of peer lookups.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
body_type, used to index in mka_body_handler, can be any u8 value, but
we have only ARRAY_SIZE(mka_body_handler) elements.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
This uses a more accurate variable type for body_type and makes it
cleaner to compare this to other unsigned values.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the memory allocation in ieee802_1x_kay_init_receive_sc() fails, we
end up in an inconsistent state where the peer is moved to the live
peers list and its sci is setup, but we don't have an rxsc.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
The room we actually use is length. This could also mess up the
receiver, since it will advance by the actual length (as indicated by
the parameter body's length), which could differ from the offset at
which we stored the next item.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
