EAP GSSAPI draft-aboba-pppext-eapgss-12 defines the use use of GSS-API mechanisms within EAP for network access control. EAP GSSAPI uses IAKERB encapsulated in GSS 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 acts as a IAKERB proxy when it recieves GSSAPI-IAKERB messages. When the client has obtained the TGT and the ST for the NAS, it issues an empty IAKERB message to the EAP server. The EAP server then issues an EAP success (!!!).

At this stage the EAP peer has authenticated the access network using the AS-REP from the KDC. However, nor the NAS nor the EAP server authenticated the EAP peer yet. For this reason, the EAP peer and NAS exchange Kerberos AP-REQ and AP-REP messages over 802.1X frames to perform mutual authentication and share keys for L2 encryption.

According to the archive and some online resources, the work on this method was abandoned for several -still standing- reasons. The most highlighted reasons 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 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 know 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.

After the AS and TGS exchange, the EAP server issues a EAP success. And from that point, Kerberos exchange over 802.1X takes place in order to authenticate the peer to the NAS. This means that the role of the EAP is not authentication but just credential acquisition only. Which is ….

EAP 3748 states the following : “The Success packet is sent by the authenticator to the peer after completion of an EAP authentication method (Type 4 or greater) to indicate that the peer has authenticated successfully to the authenticator.”

If the EAP Server/Authenticator issues an EAP-Success, this may be interpreted by other layers/applications as a successful authentication. In case of EAP-GSSAPI, this will lead to incoherence, since in EAP-GSSAPI the EAP-Success message does not mean that the EAP peer has been authenticated successfully. The actual authentication is achieved only after the AP-REQ/AP-REP exchange.

Exchanging Kerberos messages over 802.1X is not specified in any document and sounds to me like a non go approach. The goal of using EAP is in fact to avoid specifying transportation of authentication protocols over 802.1X and avoid changes to the 802.11i state machine.

The authors were right to abandon the EAP-GSSAPI authentication method for wireless networks. More because of GSSAPI limitations than Kerberos vulnerability to dictionary attacks. I believe that using Kerberos over EAP and even integrating Kerberos IN EAP would be better approach. The role of the EAP server should not only be IAKEB proxy, but also to process AP-REQ from the peer. The AP-REQ and AP-REP allows both EAP peer and server to export a key that can be used to derive MSK and EMSK. The MSK can then be transmitted to the NAS as with any other method.