eap Mailing List: [Fwd: Re: [eap] EAP Proxy question in context of 802.16e]

[Dondeti, Lakshminath (ldondeti]

<sorry if this shows up twice; my email address changed recently and I 
got a notice that my earlier email is in the moderator's queue>

Sanjay,

A few questions to set the stage for this discussion:

1. The EAP keying framework already defines (Section 2.3 in 
eap-keying-05 for instance) a key derivation mechanism to facilitate 
fast handoff. Specifically, there are key derivation functions defined 
for multiple APs or the 16e case BSs. However, that I-D does not 
separate the Authenticator and the BS/AP functionality.

Q: Why is that model insufficient in the 16e architecture? What is the 
reasoning behind separating the BS and the Authenticator functionality 
and what is the relationship between the Authenticator and the BS? I am 
curious as to which entity holds which keys and how are keys delivered 
between the 4 entities.

2. Next, what are the end-points to the Proof of Possession exchanges 
for session key derivation?

3. From the limited description, the BS is talking to the AAA server via 
a "to be defined" protocol (why not RADIUS/Diameter?). How does the AAA 
server know to deliver keys to a third (or in this case fourth) party, 
the Authenticator?

It might be worthwhile to draw a diagram similar to that in Sec 6.3 of 
the keying draft to clarify some of this. Many thanks.

best regards,
Lakshminath

Bakshi, Sanjay wrote:

> Hello,
>
> I have a question in context of application of EAP to 802.16e network.
>
> Following figure shows the typical application of EAP to an 802.16e 
> based network
>
> EAP-method EAP-method
>
> EAP EAP EAP EAP
>
> PKMv2 PKMv2 RADIUS RADIUS
>
> ---------- ------------- ----------
>
> MSS/EAP_peer BS/EAP_Authenticator AS
>
> 802.16e defines PKMv2 as the encapsulation protocol for carrying EAP 
> messages between MSS (802.16e Mobile Subscriber Station) and 
> BS(802.16e Base Station). BS acts as the RADIUS client and forwards 
> the EAP messages to the AS and vice-versa.
>
> In order to better handle mobility, following is an alternative way of 
> applying EAP model that is being considered: -
>
> EAP-method EAP-method
>
> EAP EAP EAP EAP EAP EAP
>
> PKMv2 PKMv2 ??? ??? RADIUS RADIUS
>
> ------------ ------------ ------------------------- -----------
>
> MSS/EAP_peer BS/EAP_Proxy Gateway/EAP_Authenticator AS
>
> Basically, in the context of EAP in this model BS acts as a relay and 
> implements two functions.
>
> 1. On uplink BS removes EAP pdus from the PKMv2 encapsulation, 
> encapsulates them in a “to be defined”
>
> encapsulation and forwards them to the Gateway which is a RADIUS client.
>
> 2. On downlink BS removes EAP pdus from a “to be defined” 
> encapsulation, encapsulates them in PKMv2 and
>
> forwards them to the MSS
>
> BS does not implement any Authenticator functions. Assuming that 
> appropriate encapsulation protocol is defined
>
> between BS and Gateway, does this model break any assumptions of EAP’s 
> 3-party model? Is it legal from EAP perspective?
>
> Thanks,
>
> -- Sanjay