This was reported to fail with Windows 2012r2 with "Invalid Compound_MAC
in cryptobinding TLV". It turns out that the server decided to go
through inner EAP method (EAP-MSCHAPv2 in the reported case) even when
using PEAP fast-reconnect. This seems to be against the [MS-PEAP]
specification which claims that inner EAP method is not used in such a
case. This resulted in a different CMK being derived by the server (used
the version that used ISK) and wpa_supplicant (used the version where
IPMK|CMK = TK without ISK when using fast-reconnect).
Fix this interop issue by making wpa_supplicant to use the
fast-reconnect version of CMK derivation only when using TLS session
resumption and the server having not initiated inner EAP method before
going through the cryptobinding exchange.
Signed-off-by: Jouni Malinen <j@w1.fi>
eap_peap_parse_phase1() returned 0 unconditionally, so there was no need
for that return value or the code path that tried to address the error
case.
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>
EAP-TLS was already doing this, but the other TLS-based EAP methods did
not mark methodState DONE and decision FAIL on local TLS processing
errors (instead, they left the connection waiting for a longer timeout).
Signed-off-by: Jouni Malinen <j@w1.fi>
The EAP-TLS-based helper functions can easily use struct wpabuf in more
places, so continue cleanup in that direction by replacing separate
pointer and length arguments with a single struct wpabuf argument.
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 makes the implementation less likely to provide useful timing
information to potential attackers from comparisons of information
received from a remote device and private material known only by the
authorized devices.
Signed-off-by: Jouni Malinen <j@w1.fi>
PEAPv2 implementation was not fully completed and there does not seem to
be any deployments of PEAPv2 nor any clear sign of such showing up in
the future either. As such, there is not much point in maintaining this
implementation in hostapd/wpa_supplicant.
Signed-hostap: Jouni Malinen <j@w1.fi>
This adds a new getSessionId() callback for EAP peer methods to allow
EAP Session-Id to be derived. This commits implements this for EAP-FAST,
EAP-GPSK, EAP-IKEv2, EAP-PEAP, EAP-TLS, and EAP-TTLS.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Some deployed authentication servers seem to be unable to handle the TLS
Session Ticket extension (they are supposed to ignore unrecognized TLS
extensions, but end up rejecting the ClientHello instead). As a
workaround, disable use of TLS Sesson Ticket extension for EAP-TLS,
EAP-PEAP, and EAP-TTLS (EAP-FAST uses session ticket, so any server that
supports EAP-FAST does not need this workaround).
Signed-hostap: Jouni Malinen <j@w1.fi>
This function can fail in theory since the SHA-1 functions are
allowed to return an error. While this does not really happen in
practice (we would not get this far if SHA-1 does not work), it is
cleaner to include the error handling here to keep static analyzers
happier. [Bug 421]
Signed-hostap: Jouni Malinen <j@w1.fi>
In addition, start ordering header file includes to be in more
consistent order: system header files, src/utils, src/*, same
directory as the *.c file.
Windows Server 2008 NPS gets very confused if the TLS Message Length is
not included in the Phase 1 messages even if fragmentation is not used.
If the TLS Message Length field is not included in ClientHello message,
NPS seems to decide to use the ClientHello data (excluding first six
octets, i.e., EAP header, type, Flags) as the OuterTLVs data in
Cryptobinding Compound_MAC calculation (per PEAPv2; not MS-PEAP)..
Lets add the TLS Message Length to PEAPv0 Phase 1 messages to get rid of
this issue. This seems to fix Cryptobinding issues with NPS and PEAPv0
is now using optional Cryptobinding by default (again) since there are
no known interop issues with it anymore.
Changed peer to derive the full key (both MS-MPPE-Recv-Key and
MS-MPPE-Send-Key for total of 32 octets) to match with server
implementation.
Swapped the order of MPPE keys in MSK derivation since server
MS-MPPE-Recv-Key | MS-MPPE-Send-Key matches with the order specified for
EAP-TLS MSK derivation. This means that PEAPv0 cryptobinding is now
using EAP-MSCHAPv2 MSK as-is for ISK while EAP-FAST will need to swap
the order of the MPPE keys to get ISK in a way that interoperates with
Cisco EAP-FAST implementation.
It looks like [MS-PEAP] 3.2.5.6 points towards this being the expected
behavior (however, that chapter is very confusing).
In addition, remove Cryptobinding TLV from response if the received
Cryptobinding TLV is not valid. Add some more debug messages to the case
where the received Cryptobinding TLV is found invalid.
Process SoH Request in SoH EAP Extension method and reply with SoH TLV. The
contents of SSoH is not yet complete (i.e., some of the required attributes
are still missing). Use of SoH is disabled by default; it can be enabled
with tnc=soh in phase1 parameter for PEAP.
crypto_binding=# in phase1 network parameter can now be used to change the
PEAPv0 cryptobinding behavior (0 = do not use, 1 = optional (default),
2 = required).
It looks like Microsoft implementation does not match with their
specification as far as PRF+ label usage is concerned.. IPMK|CMK is derived
without null termination on the label, but the label for CSK derivation
must be null terminated.
This allows cryptobinding to be used with PEAPv0 in a way that
interoperates with Windows XP SP3 (RC2) and as such, this functionality is
now enabled as an optional addition to PEAPv0.
Microsoft uses reverse order for MS-MPPE keys in EAP-PEAP when compared to
EAP-FAST derivation of ISK. Swap the keys here to get the correct ISK for
EAP-PEAPv0 cryptobinding. This resolves the cryptobinding interop issue
with WinXP SP3 RC2. However, it looks like MSK derivation does not
interoperate when using cryptobinding, so this code remains disabled for
the time being.
This implementation is complete for PEAPv0 (Microsoft extension), but the
use of cryptobinding is disabled in this version, i.e., this does not
change protocol behavior at all.
Interop tests between hostapd and wpa_supplicant work fine, but there are
some problems in getting hostapd to interoperate with Windows XP SP3 RC2
(peer replies with Result Failure to the attempted cryptobinding). The
implementation will remain disabled until this issue has been resolved.
EAP-PEAP was the only method that used the external eap_tlv.c peer
implementation. This worked fine just for the simple protected result
notification, but extending the TLV support for cryptobinding etc. is not
trivial with such separation. With the TLV processing integrated into
eap_peap.c, all the needed information is now available for using
additional TLVs.
