Commit graph

6 commits

Author SHA1 Message Date
Jouni Malinen
aba8dc82fc EAP-PEAP server: Support vendor EAP types in Phase 2
This was already allowed with EAP-PEAP, but EAP-TEAP was hardcoded to
use only the non-expanded EAP types. Extend that to allow vendor EAP
types to be used.

Signed-off-by: Jouni Malinen <j@w1.fi>
2019-08-17 16:17:42 +03:00
Jouni Malinen
5f2301a6da Replace EapType typedef with enum eap_type
This cleans up coding style of the EAP implementation by avoiding
typedef of an enum hiding the type of the variables.

Signed-off-by: Jouni Malinen <j@w1.fi>
2019-08-17 11:36:20 +03:00
Jouni Malinen
76ddfae6eb EAP-TEAP server: Testing mechanism for Result TLV in a separate message
The new eap_teap_separate_result=1 hostapd configuration parameter can
be used to test TEAP exchange where the Intermediate-Result TLV and
Crypto-Binding TLV are send in one message exchange while the Result TLV
exchange in done after that in a separate message exchange.

Signed-off-by: Jouni Malinen <j@w1.fi>
2019-08-17 00:08:47 +03:00
Jouni Malinen
234489efd1 EAP-TEAP server: Require Intermediate-Result TLV even with Result TLV
It is not sufficient for the peer to include only the Result TLV if the
server included both the Intermediate-Result TLV and Result TLV.

Signed-off-by: Jouni Malinen <j@w1.fi>
2019-08-17 00:08:47 +03:00
Jouni Malinen
a66e53c419 EAP-TEAP: Fix TLS-PRF for TLS ciphersuites that use SHA384
These need to be using the HMAC-based TLS-PRF with SHA384 instead of
SHA256 as the hash algorithm.

Signed-off-by: Jouni Malinen <j@w1.fi>
2019-08-16 21:16:44 +03:00
Jouni Malinen
0ed57c5ea8 EAP-TEAP server and peer implementation (RFC 7170)
This adds support for a new EAP method: EAP-TEAP (Tunnel Extensible
Authentication Protocol). This should be considered experimental since
RFC 7170 has number of conflicting statements and missing details to
allow unambiguous interpretation. As such, there may be interoperability
issues with other implementations and this version should not be
deployed for production purposes until those unclear areas are resolved.

This does not yet support use of NewSessionTicket message to deliver a
new PAC (either in the server or peer implementation). In other words,
only the in-tunnel distribution of PAC-Opaque is supported for now. Use
of the NewSessionTicket mechanism would require TLS library support to
allow arbitrary data to be specified as the contents of the message.

Signed-off-by: Jouni Malinen <j@w1.fi>
2019-07-09 16:56:02 +03:00