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

[Dondeti, Lakshminath (ldondeti]

Hi Sanjay,

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

Bakshi, Sanjay wrote:

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


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

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

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