Subject: [eap] Question on EAP-AKA trust model

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 10 Aug 2005 18:01:44 -0500

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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Fri, 12 Aug 2005 15:59:32 +0300

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:[email-masked]]
> Sent: 11 August, 2005 02:02
> To: [email-masked]
> Cc: Haverinen Henry (Nokia-ES/Jyvaskyla); 
> [email-masked]; Shin
> Min-Ho-A00057; Nakhjiri Madjid-MNAKHJI1
> Subject: Question on EAP-AKA trust model
> 
> 
>  Hi folks, authors,
> 
> 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.
> 
> 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.
>

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 12 Aug 2005 15:32:08 -0500

Hi Henry,

Thank you for your comments. Yes, I agree that fetching vectors is not part of EAP-AKA specification. I was merely asking for guidance.
Your comments confirms my understanding that the 3GPP AAA server does not share the  vectors (after fetching them from HSS) with the visited network (as it would with a VLR), which means the peer cannot authenticate to anybody but home.
I will take a look at the 29.234 to see whether I can find the AVPs that carry the Avs.

Thanks again,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 12, 2005 8:00 AM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Cc: [email-masked]; Shin Min-Ho-A00057
Subject: RE: Question on EAP-AKA trust model

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

> Cc: Haverinen Henry (Nokia-ES/Jyvaskyla); [email-masked]; 
> Shin Min-Ho-A00057; Nakhjiri Madjid-MNAKHJI1