Update the SAE-PK implementation to match the changes in the protocol
design:
- allow only Sec values 3 and 5 and encode this as a single bit field
with multiple copies
- add a checksum character
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
sae_check_confirm_pk() and sae_write_confirm_pk() were using different
checks for determining whether SAE-PK was used. It was apparently
possible to miss the checks in sae_write_confirm_pk() in some AP cases
where SAE H2E is being used. Fix this by checking sae->pk in the
write-confirm case similarly to the way this was done in check-confirm.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Debug logs did not make it clear whether the failure happens when
checking a received SAE confirm or when writing own SAE confirm. Those
cases have different checks on when to go through SAE-PK processing, so
it is useful to make this part clear in the debug log.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The 0..3 value decoded from the password was not incremented to the
actual 2..5 range for Sec. This resulted in not properly detecting the
minimum password length.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Move the FILS Public Key element and the FILS Key Confirmation element
to be separate IEs instead of being encapsulated within the SAE-PK
element. This is also removing the unnecessary length field for the
fixed-length EncryptedModifier.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This was clarified in the draft specification to not be a mandatory
requirement for the AP and STA to enforce, i.e., matching security level
is a recommendation for AP configuration rather than a protocol
requirement.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use value 2 to point to RFC 5480 which describes the explicit
indicatiotion of the public key being in compressed form.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The new sae_commit_status and sae_pk_omit configuration parameters and
an extra key at the end of sae_password pk argument can be used to
override SAE-PK behavior for testing purposes.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This maintains knowledge of whether H2E or PK was used as part of the
SAE authentication beyond the removal of temporary state needed during
that authentication. This makes it easier to use information about which
kind of SAE authentication was used at higher layer functionality.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
While this is not explicitly defined as the limit, lambda=8 (i.e., 9
characters with the added hyphen) is needed with Sec=5 to reach the
minimum required resistance to preimage attacks, so use this as an
implicit definition of the password length constraint.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
While the current implementation forces these groups to be same, that is
not strictly speaking necessary and the correct group to use here is
K_AP, not the SAE authentication group.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This adds core SAE functionality for a new mode of using SAE with a
specially constructed password that contains a fingerprint for an AP
public key and that public key being used to validate an additional
signature in SAE confirm from the AP.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
