eap Mailing List: Question on EAP-AKA trust model

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

 Hi folks, authors,

We are trying to implement the EAP-AKA process with the following topology

UMTS AuC/AAA----non-UMTS AAA server----AP/NAS----supplicant
(AAA1)                 (AAA2)
Here was what we were originally thinking:
The supplicant would respond to the EAP-ID from the NAS with an identity that 
would help the non-UMTS AAA server (AAA2) to find out where the UMTS AAA server 
(AAA1) is.
The AAA2 would ask the UMTS AuC/ AAA for the authentication vectors for the 
supplicant and then act as EAP-AKA server and complete the authentication.

We are now running into a couple of issues:

1) looking at 3G documentation it seems that the UMTS AuC does not pass the 
authentication vectors (AVs) to the AAA2, the AuC acts as AAAH and 
authenticates the supplicant itself, so basically UMTS operator does not trust 
the non-UMTS network AAA server (say WLAN) with Avs, is this understanding 
true? Or could we do it as below (in other words was the EAP-AKA intended for 
use by a visited AAA server).

2) Even if we modify that trust model and have the AAA2 authenticate the 
supplicant directly with borrowed Avs, what is the process for fetching this 
Avs, it does not seem to be specified in the draft or anywhere. We looked into 
RFC 2548 and thought may be we could use an Access Request/ Access accept 
process to pass the Avs from AAA1 to AAA2, using MS-MPPE-Send-Key, but we are 
not sure if this is appropriate and not sure what the request would be like, or 
how to encrypt the keys. So any hints are appreciated.

3) in the second model, if the identity supported by supplicant points to the 
AAA1, we are not sure how the AAA2 could be configured to not send the 
authentication request to the AAA1 and perform this locally. And at the same 
time the AAA2 will probably have to use the identity provided by the supplicant 
to AAA1 to allow the latter find the authentication credentials as well as 
direct the AAA2 to perform EAP-AKA.
Basically it seems that the EAP/ID response will be forwarded to AAA1, 
EAP/request with EAP-AKA type will also come from AAA1, but the rest of EAP-AKA 
is performed by the AAA2. So it seems that the peer-to-peer EAP model will be 
broken here.

Should we abandon the second model due to operator trust issues? Or modify the 
EAP process? Or ...

Help is appreciated.