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

[Bakshi, Sanjay (sanjay.bakshi]

Hi,
A number of questions have been asked and I have tried to collect them
in one place and answer from my perspective

1. I have never heard of an EAP implementation that has two hops from
peer to NAS. It is media independent, but it does not say it is
"number-of-hop" independent.
[<<sbakshi>>] Does EAP draft rule out this case? If yes, please point to
where that is stated and then we don't need this discussion. 
The question posed is --- can the encapsulation be changed more than
once between peer and NAS?

2. If the BS is not in touch with AAA server, and the authenticator is,
then how does the AAA server know what BSs the authenticator has trust
with?
[<<sbakshi>>] I am not an expert in this area so need guidance. Why
isn't it sufficient that AAA trusts Authenticator and Authenticator
trust BS? 
Assuming a) session keys are generated independently from AAA-key by the
MSS and Authenticator, b) there is a trust between authenticator and BS
via which the session keys are transferred from authenticator to BS c)
there is a 3-way handshake between MSS and BS to establish the
liveliness of the session keys and d) session keys are unique to each
{BS,MSS} pair.


3. 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? 
[<<sbakshi>>] Yes that is correct
MSS <-- PKMv2(EAP) --> BS <-- TBD(EAP) --> Authenticator


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

[<<sbakshi>>]
Key Organization 
MSS -- --- BS --- -- Auth'r --- -- AAA
MSK                                MSK       (Generated as part of EAP)
AAA-Key             AAA-Key        AAA-Key  (AAA-key sent by AAA to
Auth'r)
AK         AK          AK                   (AK sent by Auth'r to BS)

AK is Authentication Key (the session key in 802.16e) and is generated
per {BS, MSS} pair from the AAA-Key.
It is assumed here that Auth'r can securely download keys to BS.

I will answer to Bernard's questions in a separate email.
Thanks,
sanjay


>>-----Original Message-----
>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri [at] motorola.com]
>>Sent: Tuesday, March 22, 2005 2:12 PM
>>To: Bakshi, Sanjay; Dondeti, Lakshminath
>>Cc: eap [at] frascone.com
>>Subject: RE: [Fwd: Re: [eap] EAP Proxy question in context of 802.16e]
>>
>>Hi,
>>
>>Comments in line.
>>
>>Regards,
>>
>>Madjid
>>
>>-----Original Message-----
>>From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
>>Behalf
Of
>>Bakshi, Sanjay
>>Sent: Tuesday, March 22, 2005 12:22 PM
>>To: Dondeti, Lakshminath
>>Cc: eap [at] frascone.com
>>Subject: RE: [Fwd: Re: [eap] EAP Proxy question in context of 802.16e]
>>
>>Hi Lakshminath,
>>Please see my comments.
>>Thanks,
>>sanjay
>>
>><snip>
>>
>>>>>
>>>>> 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.
>>
>>Madjid>>As far as I understand, there are many EAP-based
authentication
>>methods out there that are using the 3-party model and I have never
heard
>>of an EAP implementation that has two hops from peer to NAS.
>>If the BS is not in touch with AAA server, and the authenticator is,
then
>>how does the AAA server know what BSs the authenticator has trust
with?
>>Also The TBD part of Autheticator-BS protocol would be interesting.
You
>>can't use RADIUS or Diameter, because otherwise the 4-party model
would be
>>pointless, and you can't use 802.16 L2, since it is backhaul. So how
can
>>802.16 specify an EAP model that does not have a protocol from its BS
to
>>the server.
>>If you do use RADIUS anyway, then you run into the proxy-chaining
security
>>problem for RADIUS.
>>
>>>>>
>>>>> 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.
>>
>>Madjid>>It is media independent, but it does not say it is
"number-of-hop"
>>independent.
>>
>>
>><snip>