EAP-TLS mutual authentication and directionality

[jfisherbah]

Our understanding is that the RFC for EAP-TLS requires mutual authentication, so we propose modifying the Module to mandate the relevant mutual authentication SFRs.

For the interface between the TOE and the NAS, is there a standard direction that the connection will always go (e.g. does the NAS as a client initiate an EAP-TLS connection with the TOE as the server, or does the TOE as a client open a persistent EAP-TLS channel to the NAS where the NAS is the server)?

The answer to this will determine whether we need to mandate FCS_TLSS_EXT.2, FCS_TLSC_EXT.2, both, or either.

[ajlaing]

It is intended that EAP-TLS (and EAP-TTLS used in this PP module) use mutual authentication. For EAP-TLS, this is required by the RFC, (for EAP-TTLS, the PP module is refining the RFC to require mutual authentication). In both cases, the authentication server is the TLS server.

EAP-TLS (and EAP-TTLS) are between the user and the authentication server, using a tunneling protocol (IPSEC, e.g.) through the NAS, though is it acceptable for the NAS to establish a TLS session between it and the authentication server. For TLS between the NAS and the authentication server, the authentication server is also the TLS server.

So, FCS_TLSS_EXT.2 (TLS server with mutual authentication) is mandatory. Depending on whether the authentication server uses external services (e.g., forwarding requests to another authentication server, validating authorization with a directory server, etc.), it might also require FCS_TLSC_EXT.2 - this might end up being selection based depending on how we capture these.

[jfisherbah]

Keeping this open right now because FCS_TLSS_EXT.2 is currently referenced as expected but FCS_TLSC_EXT.2 is not yet mentioned and it's unclear whether it's because we decided not to include it or because it's still an open question.