Use the TLS-Exporter with the label and context as defined in
draft-ietf-emu-tls-eap-types-00 when deriving keys for PEAP with TLS
1.3.
Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
EAP peer does not expect data present when beginning the Phase 2 in
EAP-{TTLS,PEAP} but in TLS 1.3 session tickets are sent after the
handshake completes.
There are several strategies that can be used to handle this, but this
patch picks up from the discussion[1] and implements the proposed use of
SSL_MODE_AUTO_RETRY. SSL_MODE_AUTO_RETRY has already been enabled by
default in OpenSSL 1.1.1, but it needs to be enabled for older versions.
The main OpenSSL wrapper change in tls_connection_decrypt() takes care
of the new possible case with SSL_MODE_AUTO_RETRY for
SSL_ERROR_WANT_READ to indicate that a non-application_data was
processed. That is not really an error case with TLS 1.3, so allow it to
complete and return an empty decrypted application data buffer.
EAP-PEAP/TTLS processing can then use this to move ahead with starting
Phase 2.
[1] https://www.spinics.net/lists/hostap/msg05376.html
Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
Allow an additional context value to be passed to TLS exporter as
specified in RFC 5705 section 4.
This does not yet implement it for the internal TLS implementation.
However, as currently nothing uses context yet, this will not break
anything right now. WolfSSL maintainers also stated that they are not
going to add context support yet, but would look into it if/when this is
required by a published draft or a standard.
Signed-off-by: Ervin Oro <ervin.oro@aalto.fi>
These buffers in TLS-based EAP methods might contain keys or password
(e.g., when using TTLS-PAP or PEAP-GTC), so clear them explicitly to
avoid leaving such material into heap memory unnecessarily.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Derive EMSK when using EAP-PEAP to enable ERP. In addition, change the
MSK derivation for EAP-PEAP to always derive 128 octets of key material
instead of the 64 octets to cover just the MSK. This is needed with the
PRF used in TLS 1.3 since the output length is mixed into the PRF
context.
Signed-off-by: Jouni Malinen <j@w1.fi>
Reduce the amount of time keying material (MSK, EMSK, temporary private
data) remains in memory in EAP methods. This provides additional
protection should there be any issues that could expose process memory
to external observers.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds support for optional functionality to validate server
certificate chain in TLS-based EAP methods in an external program.
wpa_supplicant control interface is used to indicate when such
validation is needed and what the result of the external validation is.
This external validation can extend or replace the internal validation.
When ca_cert or ca_path parameter is set, the internal validation is
used. If these parameters are omitted, only the external validation is
used. It needs to be understood that leaving those parameters out will
disable most of the validation steps done with the TLS library and that
configuration is not really recommend.
By default, the external validation is not used. It can be enabled by
addingtls_ext_cert_check=1 into the network profile phase1 parameter.
When enabled, external validation is required through the CTRL-REQ/RSP
mechanism similarly to other EAP authentication parameters through the
control interface.
The request to perform external validation is indicated by the following
event:
CTRL-REQ-EXT_CERT_CHECK-<id>:External server certificate validation needed for SSID <ssid>
Before that event, the server certificate chain is provided with the
CTRL-EVENT-EAP-PEER-CERT events that include the cert=<hexdump>
parameter. depth=# indicates which certificate is in question (0 for the
server certificate, 1 for its issues, and so on).
The result of the external validation is provided with the following
command:
CTRL-RSP-EXT_CERT_CHECK-<id>:<good|bad>
It should be noted that this is currently enabled only for OpenSSL (and
BoringSSL/LibreSSL). Due to the constraints in the library API, the
validation result from external processing cannot be reported cleanly
with TLS alert. In other words, if the external validation reject the
server certificate chain, the pending TLS handshake is terminated
without sending more messages to the server.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous PEAP client behavior allowed the server to skip Phase 2
authentication with the expectation that the server was authenticated
during Phase 1 through TLS server certificate validation. Various PEAP
specifications are not exactly clear on what the behavior on this front
is supposed to be and as such, this ended up being more flexible than
the TTLS/FAST/TEAP cases. However, this is not really ideal when
unfortunately common misconfiguration of PEAP is used in deployed
devices where the server trust root (ca_cert) is not configured or the
user has an easy option for allowing this validation step to be skipped.
Change the default PEAP client behavior to be to require Phase 2
authentication to be successfully completed for cases where TLS session
resumption is not used and the client certificate has not been
configured. Those two exceptions are the main cases where a deployed
authentication server might skip Phase 2 and as such, where a more
strict default behavior could result in undesired interoperability
issues. Requiring Phase 2 authentication will end up disabling TLS
session resumption automatically to avoid interoperability issues.
Allow Phase 2 authentication behavior to be configured with a new phase1
configuration parameter option:
'phase2_auth' option can be used to control Phase 2 (i.e., within TLS
tunnel) behavior for PEAP:
* 0 = do not require Phase 2 authentication
* 1 = require Phase 2 authentication when client certificate
(private_key/client_cert) is no used and TLS session resumption was
not used (default)
* 2 = require Phase 2 authentication in all cases
Move supplicant to idf and do following refactoring:
1. Make the folder structure consitent with supplicant upstream
2. Remove duplicated header files and minimize the public header files
3. Refactor for WiFi/supplicant interfaces
