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

[Bakshi, Sanjay (sanjay.bakshi]

Hi Lakshminath,
Please see my comments.
Thanks,
sanjay

>>-----Original Message-----
>>From: Dondeti, Lakshminath [mailto:ldondeti [at] nortel.com]
>>Sent: Monday, March 21, 2005 11:34 AM
>>To: Bakshi, Sanjay
>>Cc: eap [at] frascone.com
>>Subject: Re: [Fwd: Re: [eap] EAP Proxy question in context of 802.16e]
>>
>>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
>>
>>>
>>> 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.

[<<sbakshi>>] You are correct, but this is still in the draft state and
I am not aware of any existing implementations today. Also, I am not
sure if there have been any studies done with respect to how many
authenticators can be supported in this manner. If authenticator is on
the BS, then AAA server needs to be aware of and have trust
relationships with all the BS. 

>>>
>>> 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.

[<<sbakshi>>] Firstly, I am not clear if there are 4 entities if BS is
just a relay from EAP messaging perspective. I have heard differing
opinions on this and would like a definitive answer to that. Per my
understanding of section 1.4.1 EAP has to be media independent. It just
has some assumptions on underlying layer and as long as those are met it
should not matter how EAP is carried.
I don't think model defined in eap-keying-05 is insufficient, but I have
some questions about its scalability and actual existing deployments.

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

[<<sbakshi>>] I did not understand the question. Proof of Possession
exchanges of which session key derivation? We have key derivation from
eap-keying draft and from 802.16e specification.

>>>
>>> 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?

[<<sbakshi>>] ignoring the question per your later email :)
>>>
>>> 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
>>>