Add new configuration parameters macsec_replay_protect and
macsec_replay_window to allow user to set up MACsec replay protection
feature. Note that according to IEEE Std 802.1X-2010 replay protection
and delay protection are different features: replay protection is
related only to SecY and does not appear on MKA level while delay
protection is something that KaY can use to manage SecY state.
Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
The purpose of the Lowest Acceptable PN (lpn) parameters in the MACsec
SAK Use parameter set is to enforce delay protection. Per IEEE Std
802.1X-2010, Clause 9, "Each SecY uses MKA to communicate the lowest PN
used for transmission with the SAK within the last two seconds, allowing
receivers to bound transmission delays."
When encoding the SAK Use parameter set the KaY should set llpn and olpn
to the lowest PN transmitted by the latest SAK and oldest SAK (if
active) within the last two seconds. Because MKPDUs are transmitted
every 2 seconds (MKA_HELLO_TIME), the solution implemented here
calculates lpn based on the txsc->next_pn read during the previous MKPDU
transmit.
Upon receiving and decoding a SAK Use parameter set with delay
protection enabled, the KaY will update the SecY's lpn if the delay
protect lpn is greater than the SecY's current lpn (which is a product
of last PN received and replay protection and window size).
Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
IEEE Std 802.1X-2010, 9.3.1 defines following restrictions for CKN:
"MKA places no restriction on the format of the CKN, save that it comprise
an integral number of octets, between 1 and 32 (inclusive), and that all
potential members of the CA use the same CKN. No further constraints are
placed on the CKNs used with PSKs, ..."
Hence do not require a 32 octet long CKN but instead allow a shorter CKN
to be configured.
This fixes interoperability with some Aruba switches, that do not accept
a 32 octet long CKN (only support shorter ones).
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
In case MKA is initialized successfully, local copies of CAK and CKN
were allocated, but never freed. Ensure that such memory is released
also when ieee802_1x_kay_create_mka() returns a valid pointer.
Fixes: ad51731abf ("wpa_supplicant: Allow pre-shared (CAK,CKN) pair for MKA")
Signed-off-by: Davide Caratti <davide.caratti@gmail.com>
Instead of requiring OpenSSL headers to be available just for the
SSL3_RANDOM_SIZE definition, replace that macro with a fixed length (32)
to simplify dependencies.
Signed-off-by: Jouni Malinen <j@w1.fi>
secy_init_macsec() can fail (if ->macsec_init fails), and
ieee802_1x_kay_init() should handle this and not let MKA run any
further, because nothing is going to work anyway.
On failure, ieee802_1x_kay_init() must deinit its kay, which will free
kay->ctx, so ieee802_1x_kay_init callers (only ieee802_1x_alloc_kay_sm)
must not do it. Before this patch there is a double-free of the ctx
argument when ieee802_1x_kay_deinit() was called.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
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>
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>
This enables configuring key_mgmt=NONE + mka_ckn + mka_cak.
This allows wpa_supplicant to work in a peer-to-peer mode, where peers
are authenticated by the pre-shared (CAK,CKN) pair. In this mode, peers
can act as key server to distribute keys for the MACsec instances.
This is what some MACsec switches support, and even without HW
support, it's a convenient way to setup a network.
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>
Clean up the driver interface by passing pointers to struct receive_sc
down the stack to the {create,delete}_recevie_sc() ops, instead of
passing the individual properties of the SC.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Clean up the driver interface by passing pointers to struct transmit_sc
down the stack to the {create,delete}_transmit_sc() ops, instead of
passing the individual arguments.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Clean up the driver interface by passing pointers to struct receive_sa
down the stack to the {create,enable,disable}_receive_sa() ops, instead
of passing the individual properties of the SA.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Clean up the driver interface by passing pointers to struct transmit_sa
down the stack to the {create,enable,disable}_transmit_sa ops, instead
of passing the individual properties of the SA.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Clean up the driver interface by passing pointers to structs transmit_sa
and receive_sa down the stack to get_receive_lowest_pn(),
get_transmit_next_pn(), and set_transmit_next_pn() ops, instead of
passing the individual arguments.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
This is a known constant value (CS_ID_LEN, i.e., the length of the EUI64
identifier) and does not need to be provided separately in these
function calls.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
This is now annotated as be16, so use it as such in all cases instead of
first storing host byte order value and then swapping that to big endian
in other instances of the same structure. This gets rid of number of
sparse warnings.
Signed-off-by: Jouni Malinen <j@w1.fi>
