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

[Dondeti, Lakshminath (ldondeti]

Hi,

Just realized (on second reading) that the "to-be-defined" protocol is 
between the BS and the Authenticator.  So, please ignore the 3rd 
question below.  Thanks.

regards,
Lakshminath

Dondeti, Lakshminath [BL60:1A14:EXCH] wrote:

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