Commit graph

127 commits

Author SHA1 Message Date
Jouni Malinen
0be8b9238f mka: Avoid memory leak in unexpected case in RECEIVE
It looks like it is possible for the RECEIVE state to leak memory where
a previously allocated sm->lki is moved to sm->oki while sm->oki is
pointing to not yet freed entry. It is not clear how this can be
triggered, but it has come up in hwsim testing under heavy load.

Free sm->oki if it is still set in RECEIVE before replacing it with
sm->lki to avoid this memory leak.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
2019-04-15 22:50:06 +03:00
Jouni Malinen
abde4eba45 UBSan: Pack MACsec peer id structure
This is needed to avoid an UBSan warning and since this struct is used
as part of a message construction, it needs to be packed anyway to
guarantee correct functionality.

ieee802_1x_kay.c:1021:3: runtime error: member access within misaligned address 0x0000031921e2 for type 'struct ieee802_1x_mka_peer_id', which requires 4 byte alignment

Signed-off-by: Jouni Malinen <j@w1.fi>
2019-02-25 19:48:49 +02:00
Mike Siedzik
a07b8a70b5 mka: New MI should only be generated when peer's key is invalid
Two recent changes to MKA create a situation where a new MI is generated
every time a SAK Use parameter set is decoded.  The first change moved
invalid key detection from ieee802_1x_decode_basic_body() to
ieee802_1x_kay_decode_mpkdu():

  commit db9ca18bbf ("mka: Do not ignore MKPDU parameter set decoding failures")

The second change forces the KaY to generate a new MI when an invalid
key is detected:

  commit a8aeaf41df ("mka: Change MI if key invalid")

The fix is to move generation of a new MI from the old invalid key
detection location to the new location.

Fixes: a8aeaf41df ("mka: Change MI if key invalid")
Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2019-01-08 01:12:02 +02:00
Jouni Malinen
a1417c7f96 mka: Log MI update failure in debug log
One of the reset_participant_mi() callers did not log the error. Make
this more consistent with the other callers.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-31 01:09:02 +02:00
Jaap Keuter
23693c9dac mka: Make ICV Indicator dependant on ICV length
IEEE Std 802.1X-2010, 11.11 describes that the ICV is separate from the
parameter sets before it. Due to its convenient layout the ICV Indicator
'body part' is used to encode the ICV as well.

IEEE Std 802.1X-2010, 11.11.3 describes the encoding of MKPDUs. In
bullet e) is desribed that the ICV Indicator itself is encoded when the
ICV is not 16 octets in length. IEEE Std 802.1Xbx-2014, Table 11-7 note
e) states that it will not be encoded unless the Algorithm Agility
parameter specifies the use of an ICV that is not 16 octets in length.

Therefore the length calculation for the ICV indicator body part must
take into account if the ICV Indicator is to be encoded or not. The
actual encoder of the ICV body already takes care of the rest.

In practice, this change will remove the ICV Indicator parameter set (4
octets before the ICV value itself) since the only defined algorithm
agility value uses an ICV of 16 octets. IEEE Std 802.1X-2010 MKPDU
validation and decoding rules in 11.11.2 and 11.11.4 require the
receipient to handle both cases of ICV Indicator being included or not.

Signed-off-by: Jaap Keuter <jaap.keuter@xs4all.nl>
2018-12-30 01:03:30 +02:00
Jouni Malinen
948ba8c294 mka: MIB information
Provide MKA information through the wpa_supplicant control interface MIB
command.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-29 16:52:31 +02:00
Jouni Malinen
8c652ecfbe mka: Provide more status information over control interface
Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-29 11:05:39 +02:00
Jouni Malinen
626bc1fac2 mka: Stop trying to generate and distribute new SAK when not key server
It was possible for a participant to first be elected as a key server
and schedule a new SAK to be generated and distributed just to be
followed by another participant being elected as the key server. That
did not stop the participant that disabled key server functionality to
stop generating the new SAK and then trying to distribute it. That is
not correct behavior, so make these steps conditional on the participant
still being a key server when going through the timer.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-29 11:05:39 +02:00
Jouni Malinen
4060cb272b mka: Add more debug print details
This makes it a bit easier to try to figure out what is going on with
KaY operations and MKA setup.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-29 11:05:39 +02:00
Jouni Malinen
27859f5203 mka: Fix deleteSAs clearing of principal->new_key
This pointer needs to be cleared when the matching SAK is being removed
from the SAK list. The previous implementation was doing something
pretty strange in the loop by clearing the pointer for any non-matching
key that happened to be iterated through before finding the matching
key. This could probably result in incorrect behavior, but not clearing
the pointer for the matching key could do more harm by causing freed
memory to be referenced.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-29 11:05:39 +02:00
Jouni Malinen
4d91d4a7cc mka: Derive MACsec cipher suite and MKA algorithm table index
Instead of using a specifically set index value from table definition,
use the actual real index of the table entry. This removes need for
maintaining these index values separately. Furthermore, the
mka_alg_tbl[] index was already off-by-one (but not used anywhere).

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-29 11:05:39 +02:00
Jaap Keuter
a0bec739f1 mka: Clean up KaY log output
When running wpa_supplicant (with logging for testing) the log output is
somewhat disorganized for KaY related items. E.g., items are not
aligned, inconsistent type handling, wrong wording, missing labels, etc.
This change tries to clean up the log output, so it is somewhat more
accessible.

Signed-off-by: Jaap Keuter <jaap.keuter@xs4all.nl>
2018-12-27 16:03:46 +02:00
Jouni Malinen
1cb5082567 mka: Do not force entry into INIT state on CP state machine creation
Go through the SM_STEP_RUN() global transition to get into the INIT
state to follow the state machine design more closely.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-27 11:33:46 +02:00
Jouni Malinen
785b219abd mka: Remove unused authorization data from CP
While IEEE Std 802.1X-2010 talks about arbitrary authorization data that
could be passed to the CP from sources like RADIUS server, there is not
much point in trying to implement this as an arbitrary memory buffer in
wpa_supplicant. Should such data be supported in the future, it would
much more likely use more detailed data structures that encode the
received data in easier to use form.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-27 11:26:27 +02:00
Jouni Malinen
7251f0badc mka: Extend CAK/CKN-from-EAP-MSK API to pass in MSK length
This can be used to allow 256-bit key hierarchy to be derived from
EAP-based authentication. For now, the MSK length is hardcoded to 128
bits, so the previous behavior is maintained.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-26 16:44:58 +02:00
Jouni Malinen
7a29984888 mka: Allow CAK length 32 (256-bit) to be initialized
The CAK length is not hardcoded in the algorithm agility parameter, so
remove that from the table. Instead, allow both 16 (128-bit) and 32
(256-bit) CAK to be used so that the following key derivations use
appropriate key lengths based on the configured/derived CAK.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-26 16:44:58 +02:00
Jouni Malinen
73111a63cc mka: Determine KCK/ICK length from CAK length
The ICK and KEK are derived from a CAK and the length of the CAK
determines the length of the KCK/ICK. Remove the separate ICK/KEK length
parameters from the algorithm agility table.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-26 16:44:58 +02:00
Jouni Malinen
b452a76e54 mka: ICV calculation using 256-bit ICK
Add support for using AES-CMAC with 256-bit key (ICK) to calculate ICV.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-26 16:44:58 +02:00
Jouni Malinen
7c3d1cc040 mka: Support 256-bit ICK derivation
Support derivation of a 256-bit ICK and use of a 256-bit CAK in ICK
derivation.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-26 16:44:58 +02:00
Jouni Malinen
175ebc1f7a mka: Support 256-bit KEK derivation
Support derivation of a 256-bit KEK and use of a 256-bit CAK in KEK
derivation.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-26 16:44:58 +02:00
Jouni Malinen
9b4a266694 mka: Support 256-bit CAK in SAK derivation
Pass the configured CAK length to SAK derivation instead of using
hardcoded 128-bit length.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-26 16:42:26 +02:00
Jouni Malinen
9dd701c12e mka: AES-CMAC-256 -based KDF
Extend the previously implemented KDF (IEEE Std 802.1X-2010, 6.2.1) to
support 256-bit input key and AES-CMAC-256. This does not change any
actual key derivation functionality yet, but is needed as a step towards
supporting 256-bit CAK.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-26 16:42:26 +02:00
Andrey Kartashev
a8aeaf41df mka: Change MI if key invalid
It is possible to get a situation where a peer removes the Key Server
from its live peers list but the server still thinks that the peer is
alive (e.g., high packet loss in one direction). In such a case, the Key
Server will continue to advertise Last Key but this peer will not be
able to set up SA as it has already deleted its key.

Change the peer MI which will force the Key Server to distribute a new
SAK.

Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
2018-12-26 16:42:26 +02:00
Andrey Kartashev
c20cc5833e mka: Speed up processing of duplicated SCI
Decrease timeout for a peer with duplicated SCI to speed up process in
case it is a valid peer after MI change.

Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
2018-12-26 16:42:25 +02:00
Andrey Kartashev
c1576d44a8 mka: Support for 256-bit SAK generation
There is already partial support of GCM-AES-256. It is possible to
enable this mode by setting 'kay->macsec_csindex = 1;' in
ieee802_1x_kay_init() function, but the generated key contained only 128
bits of data while other 128 bits are in 0.

Enables KaY to generate full 256-bit SAK from the same 128-bit CAK. Note
that this does not support 256-bit CAK or AES-CMAC-256 -based KDF.

Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
2018-12-26 16:42:25 +02:00
Andrey Kartashev
c9c93e7a24 mka: Remember LowestPN for each key server
According IEEE Std 802.1X-2010, 9.8 each participant shall record the
values of NextPN for last SAK accepted from each Key Server to use it in
case of a switch from one Key Server to another and back. Add LPN
recording and set saved value as the initial PN for the created channel.

Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
2018-12-26 16:42:25 +02:00
Andrey Kartashev
54c6a69952 mka: Check for errors on create Secure Channel
It is possible that the driver fails to create Secure Channel (due to
hardware limitations for example). Add checks of create_*_sc() result
codes and abort procedure in case of failure.

Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
2018-12-26 16:42:25 +02:00
Andrey Kartashev
52171e18c9 mka: Fix a memory leak on error path
Fix a minor memory leak in ieee802_1x_kay_create_mka() in
case of KEK/ICK derivation failure.

Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
2018-12-26 16:42:25 +02:00
Andrey Kartashev
a6cd1be957 mka: Debug output cleanup/fix
Make debug output more consistent, fix several errors.

Signed-off-by: Andrey Kartashev <andrey.kartashev@afconsult.com>
2018-12-26 16:42:25 +02:00
Andrey Kartashev
e49b78c0d5 mka: Allow configuration of MACsec replay protection
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>
2018-12-26 16:42:25 +02:00
Mike Siedzik
302bbad5ac mka: Do not update potential peer liveness timer
To prevent a remote peer from getting stuck in a perpetual 'potential
peer' state, only update the peer liveness timer 'peer->expire' for live
peers and not for potential peers.

Per IEEE Std 802.1X-2010, 9.4.3 (Determining liveness), potential peers
need to show liveness by including our MI/MN in their transmitted MKPDU
(within potential or live parameter sets).

When a potential peer does include our MI/MN in an MKPDU, we respond by
moving the peer from 'potential_peers' to 'live_peers'.

If a potential peer does not include our MI/MN in an MKPDU within
MKPDU_LIFE_TIME, let the peer expire to facilitate getting back in sync
with the remote peer.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Mike Siedzik
e4ae284bba mka: Consider missing MKPDU parameter sets a failure
The previous commit introduced parameter set error checking. This commit
extends upon that by considering missing parameter sets a failure.

Two checks are added by this commit. First, verify that live peers start
encoding MKA_SAK_USE within a reasonable amount of time after going live
(10 MKPDUs). Second, verify that once a live peer starts encoding
MKA_SAK_USE it continues to do so indefinitely.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Mike Siedzik
db9ca18bbf mka: Do not ignore MKPDU parameter set decoding failures
The status values returned by mka_param_body_handler.body_rx functions
are currently ignored by ieee802_1x_kay_decode_mkpdu(). If a failure is
detected the KaY should (a) stop processing the MKDPU and (b) do not
update the associated peer's liveliness.

IEEE Std 802.1X-2010, Table 11-7 (MKPDU parameter sets) and 11.11.3
(Encoding MKPDUs) dictate that MKA_SAK_USE (set type 3) will always be
encoded before MKA_DISTRIBUTED_SAK (set type 4) in MKPDUs. Due to
implementation of mka_param_body_handler, the code will always decode
MKA_SAK_USE before MKA_DISTRIBUTED_SAK. When MKA_DISTRUBUTED_SAK
contains a new SAK the code should decode MKA_DISTRUBUTED_SAK first so
that the latest SAK is in known before decoding MKA_SAK_USE.

The ideal solution would be to make two passes at MKDPU decoding: the
first pass decodes MKA_DISTRIBUTED_SAK, the second pass decodes all
other parameter sets.

A simpler and less risky solution is presented here: ignore MKA_SAK_USE
failures if MKA_DISTRIBUTED_SAK is also present. The new SAK will be
saved so that the next MKPDU's MKA_SAK_USE can be properly decoded. This
is basically what the code prior to this commit was doing (by ignoring
all errors).

Also, the only real recourse the KaY has when detecting any bad
parameter set is to ignore the MKPDU by not updating the corresponding
peer's liveliness timer, 'peer->expire'.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Mike Siedzik
bab1d0d359 mka: Fix resource leak when detecting duplicated SCI
If a live peer ever changes its Member Identifier (MI), the KaY
correctly detects a "duplicated SCI" but then proceeds to delete the
peer without deleting the peer's resources (i.e., RxSC, RxSAs, TxSAs).

Note that a remote peer's MI will change if and when an
ieee8021XPaePortInitialize is executed on the remote port.

The solution here is to ignore all MKPDUs containing the new MI until
after the peer (that corresponds to the old MI) expires and cleans up
its resources. After the old peer is removed reception of the next MKPDU
containing the new MI will result in the creation of a new peer with the
new MI.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Mike Siedzik
1cb0f63b0e mka: Fix READY to TRANSMIT logic in CP state machine
Per IEEE Std 802.1X-2010, Figure 12-2 (CP state machine), READY to
TRANSMIT transition includes !controlledPortEnabled condition.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Mike Siedzik
8ae29b4e9c mka: Fix READY to ABANDON logic in CP state machine
Per IEEE Std 802.1X-2010, Figure 12-2 (CP state machine), READY should
move to ABANDON (not RECEIVE) when new_sak or changed_connect is true.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Mike Siedzik
3dce43ba5f mka: Fix RECEIVING to TRANSMIT logic in CP state machine
Per IEEE Std 802.1X-2010, Figure 12-2 (CP state machine), RECEIVING to
TRANSMIT transition includes !controlledPortEnabled condition.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Mike Siedzik
06e06a8df7 mka: Fix RETIRE state deletion of SAs
Per IEEE Std 802.1X-2010, Figure 12-2 (CP state machine), deleteSAs(oki)
is used upon entering RETIRE. Do that in addition to freeing sm->oki.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Mike Siedzik
2fc0675683 mka: Fix lowest acceptable Packet Number (LPN) calculation and use
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>
2018-12-26 16:42:25 +02:00
Mike Siedzik
d9a0a72229 mka: Fix MKPDU SAK Use Body's Delay Protect bit setting
Delay Protect and Replay Protect are two separate and distinct features
of MKA. Per IEEE Std 802.1X-2010, 9.10.1 "Delay Protect, TRUE if LPNs
are being reported sufficiently frequently to allow the recipient to
provide data delay protection. If FALSE, the LPN can be reported as
zero", and per 9.10 "NOTE--Enforcement of bounded received delay
necessitates transmission of MKPDUs at frequent (0.5 s) intervals, to
meet a maximum data delay of 2 s while minimizing connectivity
interruption due to the possibility of lost or delayed MKPDUs."

This means struct ieee802_1x_mka_sak_use_body::delay_protect should only
be set TRUE when MKPDUs are being transmitted every 0.5 s (or faster).
By default the KaY sends MKPDUs every MKA_HELLO_TIME (2.0 s), so by
default delay_protect should be FALSE.

Add a new 'u32 mka_hello_time' parameter to struct ieee802_1x_kay. If
delay protection is desired, the KaY initialization code should set
kay->mka_hello_time to MKA_BOUNDED_HELLO_TIME (500 ms).

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Mike Siedzik
5864545492 mka: Fix conf_offset value in MKPDU when in policy mode SHOULD_SECURE
Commit 7b4d546e ("wpa_supplicant: Add macsec_integ_only setting for
MKA") introduced policy setting SHOULD_ENCRYPT (MACsec provides
integrity+confidentiality) in addition to SHOULD_SECURE (MACsec provides
integrity only). In both cases the KaY is populating the
"Confidentiality Offset" parameter within the "Distributed SAK parameter
set" with CONFIDENTIALITY_OFFSET_0=1. In the case of SHOULD_SECURE the
parameter should be populated with CONFIDENTIALITY_NONE=0.

IEEE Std 802.1X-2010, Table 11-6 and Figure 11-11 define how the two
Confidentiality Offset bits in the "Distributed SAK parameter set" must
be set: "0 if confidentiality not used" and "1 if confidentiality with
no offset". When policy is SHOULD_SECURE KaY should to send the former,
and when policy is SHOULD_ENCRYPT KaY should send the latter.

Fixes: 7b4d546e3d ("wpa_supplicant: Add macsec_integ_only setting for MKA")
Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-12-26 16:42:25 +02:00
Michael Braun
61127f162a MKA: Handle unaligned CKN length
IEEE Std 802.1X-2010, Figure 11-7 explains that "Parameter set body
length" is exclusive of the suffix padding.

Fix variable length encoding and decoding when CKN length is not a
multiple of 4 bytes.

Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
2018-12-25 17:29:15 +02:00
Jouni Malinen
f1ac2b8e6a MKA: Mark frame structs packed
Mark the data structures used in construction/parsing frames packed to
prevent compiler from being able to pad them.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-12-25 17:29:15 +02:00
xiaofeis
1ff8605775 mka: Support GCM-AES-256
GCM-AES-256 cipher suite is defined in IEEE Std 802.1AEbn-2011.

If authenticator configured as GCM-AES-256, the distributed SAK will be
256 bits indicated by the GCM-AES-256 ID in the MKA packet.

This patch will make AES Key Unwrap to 32 bytes of SAK when identify the
ID.

Signed-off-by: xiaofeis <xiaofeis@codeaurora.org>
2018-08-21 19:28:20 +03:00
Jouni Malinen
cce16e43f8 mka: Mark ieee802_1x_kay_create_mka() ckn and cak arguments const
These structures are not modified or freed (i.e., only data from them is
copied), so mark the arguments const to document this a bit more clearly
now that there was a memory leak in one of the callers to this function.

Signed-off-by: Jouni Malinen <j@w1.fi>
2018-03-11 17:04:34 +02:00
Mike Siedzik
3a52f6b387 mka: Do not print contents of SAK to debug log
Log newly generated SAKs as well as unwrapped SAKs with wpa_hexdump_key()
rather than wpa_hexdump(). By default, the wpa_hexdump_key() function
will not display sensitive key data.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-03-11 16:52:56 +02:00
Mike Siedzik
77977b3d5d mka: Detect duplicate MAC addresses during key server election
In the unlikely event the local KaY and the elected peer have the same
actor priority as well as the same MAC address, log a warning message
and do not elect a key server. Resolution is for network administrator
to reconfigure MAC address.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-03-11 16:49:00 +02:00
Mike Siedzik
5762855abd mka: Loss of live peers to result in connect PENDING not AUTHENTICATED
When the number of live peers becomes 0 the KaY was setting
kay->authenticated true and telling the CP to connect AUTHENTICATED.
Per IEEE Std 802.1X-2010 Clause 12.2, MKA.authenticated means "the Key
Server has proved mutual authentication but has determined that
Controlled Port communication should proceed without the use of MACsec",
which means port traffic will be passed in the clear.

When the number of live peers becomes 0 the KaY must instead set
kay->authenticated false and tell the CP to connect PENDING. Per Clause
12.3 connect PENDING will "prevent connectivity by clearing the
controlledPortEnabled parameter."

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-03-11 16:43:12 +02:00
Mike Siedzik
8fb546d8e6 mka: Ignore MACsec SAK Use Old Key parameter if we don't have our old key
Upon receipt of the "MACsec MKPDU SAK Use parameter set" the KaY verifies
that both the latest key and the old key are valid. If the local system
reboots or is reinitialized, the KaY won't have a copy of its old key.
Therefore if the KaY does not have a copy of its old key it should not
reject MKPDUs that contain old key data in the MACsec SAK Use parameter.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-03-11 16:30:29 +02:00
Mike Siedzik
b54b53e644 mka: When matching CKNs ensure that lengths are identical
KaY looks up participants using CAK Name (CKN). Per IEEE Std 802.1X-2010
Clause 9.3.1 CAK identification, the CKN is an integral number of
octets, between 1 and 32 (inclusive). This fix will ensure that the KaY
does not inadvertently match CKNs such as 'myCakNamedFoo' and
'myCakNamedFooBar'.

Signed-off-by: Michael Siedzik <msiedzik@extremenetworks.com>
2018-03-11 13:33:39 +02:00