eap Mailing List: RE: Question on EAP-AKA trust model

[henry.haverinen (henry.haverinen]

Hello Madjid,

EAP-AKA defines the EAP method between the peer
and the EAP server. The system architecture is not
in the scope of the EAP-AKA document. In particular, how 
the vectors are retrieved and the protocols between the 
EAP server and the AuC are not EAP-AKA issues. 

In 3GPP, the system architecture is discussed in TS 23.234.
The EAP server is included in the 3GPP AAA server, which is
a home operator element. The Wx reference point between the AAA
server and the HSS is based on Diameter (TS 29.234). Alternatively, a legacy 
MAP  interface (D') can be used to fetch vectors from a legacy HLR. 
In both cases, routing to the HSS/HLR is ultimately based on the IMSI.

I don't have the 3GPP2 document numbers right now, but to my 
recollection the status is similar: the EAP server is considered a home 
operator element. So authentication vectors are not sent to the visited network.
The visited network may still deploy an AAA proxy server, such as the 3GPP 
AAA proxy discussed in 3GPP TS 23.234.

I hope this helps.

Henry

> -----Original Message-----
> From: ext Nakhjiri Madjid-MNAKHJI1 
> [mailto:Madjid.Nakhjiri [at] motorola.com]
> Sent: 11 August, 2005 02:02
> To: eap [at] frascone.com
> Cc: Haverinen Henry (Nokia-ES/Jyvaskyla); 
> jari.Arkko [at] ericsson.com; Shin
> Min-Ho-A00057; Nakhjiri Madjid-MNAKHJI1
> Subject: Question on EAP-AKA trust model
> 
> 
>  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.
>