EAP GSSAPI draft-aboba-pppext-eapgss-12 defines the use use of GSS-API mechanisms within EAP for network access control. In this article, we review this proposal while applying Kerberos V GSSAPI and IAKERB GSSAPI mechanisms and see how they would work with EAP to perform network access control.

EAP GSSAPI would use IAKERB messages encapsulated in GSSAPI packets between the EAP peer and the EAP server in order to allow the peer to obtain Kerberos credentials (TGT and ST). The EAP server thus acts as an IAKERB proxy between the EAP peer and the KDC. When the client obtains the TGT and the ST for the NAS, it negotiates the use of Kerberos V GSSAPI method. This allows the client and the EAP Server to perform mutual authentication through an AP exchange.

As said in the draft, the actual authentication between the peer and the NAS can occur out-of-band by having the EAP peer and NAS exchanging Kerberos AP-REQ and AP-REP messages over 802.1X frames.

According to the archives and some online resources, the work on this method was abandoned for several still-standing reasons. The most highlighted ones are the following :

It is a known fact that Kerberos passwords can be cracked offline if an attacker can intercept an AS-REP message. While this is a valid reason for not using Kerberos as it is specified for wireless access control. This is not a reason for not attempting find a solution within EAP or 802.11i to compensate the weakness of Kerberos. Or even better, this is another motivation for thinking of a solution to resolve this vulnerability in an update to RFC 4120.

It is very difficult to overcome this obstacle. RFC 4017 “EAP Method Requirements for Wireless LANs”, states in section 2.2

  "EAP method supporting key derivation MUST export a Master Session Key (MSK)
   of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets."

The EAP GSSAPI specification reports this issue in section 4.1, and 5.5. Basically, GSSAPI offers functions to only encrypt and sign messages using the master key generated as result of the GSSAPI authentication. The specification of GSASPI suggests the use of one of these functions (wrap) to export the MSK and EMSK from the GSSAPI. However, these functions are not tailored for key derivation and do not offer enough entropy. At least random nonces must be used as input to the wrap function, and this nonce must be known to both the EAP peer and server. But there is no way for sharing such nonce with GSSAPI. So, the only remaining alternative, is to use a known string as input to the wrap function. Which makes the resulting key weak.

Labels: kerberos, wireless, security