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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 22 Mar 2005 16:11:38 -0600

Hi, 

Comments in line.

Regards,

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bakshi, Sanjay
Sent: Tuesday, March 22, 2005 12:22 PM
To: Dondeti, Lakshminath
Cc: [email-masked]
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>
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Bakshi, Sanjay" <[email-masked]>
Date: Tue, 22 Mar 2005 15:20:07 -0800

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

>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
>>Sent: Tuesday, March 22, 2005 2:12 PM
>>To: Bakshi, Sanjay; Dondeti, Lakshminath
>>Cc: [email-masked]
>>From: [email-masked] [mailto:[email-masked]] On Behalf
Of
>>Bakshi, Sanjay
>>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.
>>Madjid>>It is media independent, but it does not say it is
"number-of-hop"
>>independent.