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

From: "Bakshi, Sanjay" <[email-masked]>
Date: Tue, 22 Mar 2005 10:22:19 -0800

Hi Lakshminath,
Please see my comments.
Thanks,
sanjay

>>-----Original Message-----
>>From: Dondeti, Lakshminath [mailto:[email-masked]]
>>Sent: Monday, March 21, 2005 11:34 AM
>>To: Bakshi, Sanjay
>>Cc: [email-masked]
>>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
>>> [email-masked]
>>> http://mail.frascone.com/mailman/listinfo/eap
>>>

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Tue, 22 Mar 2005 14:50:43 -0500

Hi Sanjay,

Thanks for the clarifications.  Please see inline for follow-up comments.

>relationships with all the BS. 
Agreed that the keying framework can be revised if there are any 
requirements that it does not address today.  It might be worthwhile to 
make your case in detail so that any use cases not already covered might 
be incorporated into that draft.

On the specifics of the case you present,  I am trying to figure out the 
actual impact of separating the BS and the Authenticator functionality.  
The questions are the same as before: who has which keys and how are 
they established/delivered etc.

>some questions about its scalability and actual existing deployments.
If the BS is truly a relay and does not engage in any crypto, you are 
probably right (I would need to see a full description to be more 
concrete on this), but from your description of EAP encapsulation, it 
appears that the BS is the peer for the PKMv2 protocol.  Is that an 
incorrect assessment? 

If the BS is the peer for the PKMv2 protocol, then it engages in secure 
data encapsulation/decapsulation and therefore there is a key delivery 
there.  Please clarify this, so we can explore what's involved in detail.

>eap-keying draft and from 802.16e specification.
Apologies for the confusion.  I mean the process of the transient 
session key derivation by this.  I think Bernard asked this question as 
well.  Appendix D of the keying draft contains an example from the 
802.11 RSN specification.

Thanks.

regards,
Lakshminath