Subject: RE: [AAA-WG]: use of EAP over IKEv2

From: <[email-masked]>
Date: Tue, 6 Apr 2004 13:19:54 +0300

Hi,

I think that in most cases the EAP server does not 
actually have to know anything about IKEv2. EAP methods 
generate a Master Session Key (MSK) that is sent to 
the IKEv2 gateway, and then used to generate the AUTH 
payloads. The situation is a bit different if the EAP 
method has "channel bindings", but none of the currently
used methods has them.

However, I agree that an AVP for specifying IKEv2 service
could be still useful... or even better, a "IKEv2 RADIUS/
Diameter usage guidelines" document (like RFC3580 is 
for 802.1X). And no, I'm not volunteering to write that :-) 
Maybe people involved with VPN products might be interested,
especially considering that many existing VPN gateways
already support RADIUS?

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext David Mariblanca (ML/EEM)
> Sent: Tuesday, April 06, 2004 12:23 PM
> To: [email-masked]'
> Subject: [AAA-WG]: use of EAP over IKEv2
> 
> 
> 
> 
> Hi,
> I have found a problem when EAP is used over IKEv2 and I 
> would appreciate some help on the issue.
>
> When EAP is carried over IKEv2, a common situation is that 
> the host where EAP terminates is not the same as for IKEv2. 
> In that case, the IKEv2 termination point unpacks the IKEv2 
> messages, take the EAP messages and forwards them to the EAP 
> termination point over RADIUS or Diameter.
>
> The problem I see is that the EAP server has no way to know 
> that these EAP messages are being carried over IKEv2. This 
> knowledge is important for the EAP server, for example to 
> derive keys that will be used to generate AUTH payloads in IKEv2. 
>
> The service type AVP does not have a reserved value for this, 
> and I don't find any other suitable parameter to convey this 
> information. How could this be done ?
> 
> Thanks a lot and best regards,
> David.
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 Apr 2004 13:36:47 +0300

> the IKEv2 gateway, and then used to generate the AUTH 

Agreed.

> method has "channel bindings", but none of the currently

(There are beginnings of channel binding support in some
methods, but I'm not aware of those features being used yet.)

In any case, even if you do channel bindings the MSK stays
the same. Its just that the authentication server wants in
addition some verification of the claimed service types.

In EAP WG, we have in the past discussed about the possibility
of including the service type and parameters, such as the
SSID, in the key generation when we go from the MSK to the
AAA key. However, it seems that we have a consensus that
it would not be a good approach, primarily due to getting
different key generation formula everytime someone invents
new parameters that have to be protected. The channel
binding approach avoids this problem.

> especially considering that many existing VPN gateways

Hmm... here's a question: assuming there would be someone
who would be willing to do this, where could the work take
place? A couple of observations: IPsec and AAA WGs are closing
down and RADEXT has a pretty full charter already.

--Jari