Chris, Marcus See attached documents about EAP-FAST and EAP-GTC from Fusion 2.55 training from 2007. MC31xx is running Fusion 3.x, but I believe the same principles will apply. Hope this helps.

Out of curiosity, can you see if a device running Fusion 2.57 (MC3000, MC70, MC9090) can work fine with just one profile using GTC as the inner tunnel?  The reason I ask is that starting with Fusion 3.00, we use a different authentication supplicant, and I am wondering if that is where the problem comes in. Thanks, Dave

I also tried this on an MC9090 running WM5 (OEM version 1.43) and an MC75 running WM6.1 (OEM version 2.35.0001). I dont have the MC9090 in my posession so I dont kno wthe fusion version, but the MC75 is running Fusion version 3.00.0.0.304R. Both of these devices and the MC3190CE required that I use both an MSCHAP and a GTC profile. The MSCHAP profile allowed me to get the PAC. After I had a PAC on the device I only needed the GTC profile

 

Summary...MC9090 (WM5), MC75 (WM61.) and MC3190 (CE) required 2 profiles to oblatin a PAC and

I have what may be a similar issue.  I have tried both MC3190 CE6 and WM6.5.  EAP/TLS will authenticate the first time just fine, but will not re-authenticate after a suspend resume.  PEAP on the same device, same radius server works fine after suspend resume. I am traveling to the site tomorrow to take traces and open a case.

I was able to get EAP-FAST to work with Juniper SBR..This may be of interest to the community EAP-FAST 

EAP fast utilizes internal and  external  authentication  . The external authentication  is used to obtain a PAC which is then used in the internal authentication process. Typically, the PAC is provided by the radius server and is stored on the MU (Wireless client machine). Once the device has a PAC only the internal tunnel must be formed which reduces the overall authentication time. The protocol can use different authentication methods for the internal and external  tunnels. In the environment using Steel Belted Radius EAP-MSCHAPv2 is used to obtain a PAC (if needed) and then uses the PAC to process the inner authentication which is GTC

The problem we encountered at Bosch was that when we configured the WLAN profile to use MSCHAPv2 the device could obtain a PAC, but could not complete the inner authentication successfully since the radius server was expecting GTC as the authentication type. If we configure the WLAN profile to use GTC, the MU will successfully authenticate as long as it has a useable PAC, but if the PAC is removed or expires, there is no way for it to obtain a PAC

As a work around, we configured 2 EAP-FAST WLAN profiles (eap-pac & eap-fast). One with MSCHAPv2 as the authentication method and the other  using GTC as the authentication method. The order of these did not affect functionality but I suspect that best performance would be obtained by placing the eap-fast profile first since typically the MU will already have a PAC. It seems that the Motorola Fusion drivers will continue to cycle through the available profiles until it can connect. If the PAC is missing, it will fail the eap-fast profile and move on to the eap-pac profile and obtain a PAC. Eventually it will fail and move on to the eap-fast profile and since it now has a PAC, it will authenticate

Interestingly, an Intermec which the customer had was able to authenticate using a single WLAN profile, which seems to indicate that the Motorola  fusion stack is not as flexible and possibly is defective

 

Excerpt from Juniper Steel Belted Radius Admin Guide

EAP-FAST works in three phases:

In Phase 0, a client without a valid PAC opens a connection through a RAS to the Steel-Belted Radius server. Steel-Belted Radius uses EAP-MS-CHAPv2 to authenticate the user. If authentication is successful, Steel-Belted Radius generates a PAC for the user. and returns an Access-Reject message that contains the PAC. If a client already has a valid PAC, Phase 0 is omitted.Steel-Belted Radius Administration Guide 132 EAP-FAST

In Phase 1, the client and the Steel-Belted Radius server establish a TLS tunnel based on the PAC presented by the user. During Phase 1, the server verifies that the PAC presented by the client was generated by its current or retired server secret.

In Phase 2, the server authenticates the user or machine credentials using EAP-GTC inside the protected TLS tunnel. If the PAC is valid and the user’s credentials are correct, the authentication succeeds and Steel-Belted Radius returns an Access-Accept message. If the user’s PAC is due to expire soon, Steel-Belted Radius provisions the client with a new PAC over the secure network connection at the end of Phase 2.