Most protocols extracting keys from TLS use RFC 5705 exporters which is
commonly implemented in TLS libraries. This is the mechanism used by
EAP-TLS. (EAP-TLS actually predates RFC 5705, but RFC 5705 was defined
to be compatible with it.)
EAP-FAST, however, uses a legacy mechanism. It reuses the TLS internal
key block derivation and derives key material after the key block. This
is uncommon and a misuse of TLS internals, so not all TLS libraries
support this. Instead, we reimplement the PRF for the OpenSSL backend
and don't support it at all in the GnuTLS one.
Since these two are very different operations, split
tls_connection_prf() in two. tls_connection_export_key() implements the
standard RFC 5705 mechanism that we expect most TLS libraries to
support. tls_connection_get_eap_fast_key() implements the
EAP-FAST-specific legacy mechanism which may not be implemented on all
backends but is only used by EAP-FAST.
Signed-Off-By: David Benjamin <davidben@google.com>
Free the allocated structure in error cases to remove need for each EAP
method to handle the error cases separately. Each registration function
can simply do "return eap_server_method_register(eap);" in the end of
the function.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Reorder terms in a way that no invalid pointers are generated with
pos+len operations. end-pos is always defined (with a valid pos pointer)
while pos+len could end up pointing beyond the end pointer which would
be undefined behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
The EAP server is not yet capable of using TLS session ticket to resume
a session. Explicitly disable use of TLS session ticket with
EAP-TLS/TTLS/PEAP to avoid wasting resources on generating a session
ticket that cannot be used for anything.
Signed-off-by: Jouni Malinen <j@w1.fi>
If TLS encryption fails, encr may be NULL and that would have resulted
in NULL pointer dereference..
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Commit e8c08c9a36 ('EAP-FAST server: Fix
potential read-after-buffer (by one byte)') changed the while loop
design in a way that does not require the pos variable to be updated
anymore. Remove that unneeded code to clean up static analyzer warnings
about unused assignments.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds kek_len argument to aes_wrap() and aes_unwrap() functions and
allows AES to be initialized with 192 and 256 bit KEK in addition to
the previously supported 128 bit KEK.
The test vectors in test-aes.c are extended to cover all the test
vectors from RFC 3394.
Signed-off-by: Jouni Malinen <j@w1.fi>
The special PAC_OPAQUE_TYPE_PAD case did not skip incrementing of the
pos pointer and could result in one octet read-after-buffer when parsing
the PAC-Opaque data.
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>
Use size_t instead of int for storing and comparing the TLV length
against the remaining buffer length to make this easier for static
analyzers to understand.
Signed-off-by: Jouni Malinen <j@w1.fi>
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.
The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
This indicates that the peer identity is associated with the
credential and will be required to match with the identity used
during authentication when the PAC is used (RFC 5422, 4.2.4).
