eap Mailing List: RE: Re: IEEE 802.16e EAP usage modes

[Bakshi, Sanjay (sanjay.bakshi]

Hi Bernard,
I have tried to answer your questions below as best as I can. I need to
provide more details in order to fully answer some your questions. But
one thing is apparent, 802.16e follow the eap-keying-06 upto the point
of delivery of AAA-Key to authenticator. But Security Association
Protocol is not followed fully as detailed in the eap-keying-06.


Following is more generalized version of my question that I had earlier
asked. I prefer not to get dragged into overall 802.16e security
analysis over the email at this point. The question is:

What are the issues with having multiple relaying/switching devices
between  a Peer and an Authenticator .. specifically a pass-thru
Authenticator?

Issues that come to my mind are 
   a) MTU discovery 
      For the minimum MTU of 1020 specified in RFC3748 can be used
   b) Channel Binding
      Are there any EAP methods that implement this?
      It is not clear to me how Channel Binding is implemented when
pass-
      thru authenticator is in use. This because the Channel (lower
layer)
      between peer and pass-thru authenticator is different from the
lower 
      layer between pass-thru authenticator and AAA backend that execute
the 
      EAP method.
      Is my understanding correct?

Appreciate answers/clarifications to these.
Thanks,
--sanjay

>>-----Original Message-----
>>From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
>>Behalf
Of
>>Bernard Aboba
>>Sent: Monday, March 21, 2005 8:22 PM
>>To: eap [at] frascone.com
>>Subject: [eap] Re: IEEE 802.16e EAP usage modes
>>
>>The EAP Key Management Framework includes security requirements for
EAP
>>usage modes.  In particular, the "Housley Criteria" describes the
>>requirements for publication of AAA key management documents in the
IETF.
>>My advice would be to look carefully at those requirements in order to
>>understand whether 802.16e is compliant or not.

[<<sbakshi>>] The question I am asking is not related to AAA key
management but I will nevertheless check the document

>>
>>> 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.
>>
>>Does the uplink BS perform any cryptographic operations on data or EAP
>>packets?  Or does it just encapsulate/decapsulate packets?

[<<sbakshi>>] It just encapsulates/decapsulates EAP packets. However,
data from application sessions is encrypted. 



>>
>>>  2. On downlink BS removes EAP pdus from a "to be defined"
>>> encapsulation, encapsulates them in PKMv2 and forwards them to the
MSS
>>
>>Where are cryptographic keys stored in this architecture?  On the MSS?
on
>>the BS?  On both? How are the keys transported?  How many parties
possess
>>them?

[<<sbakshi>>] 
Main keys on MSS (peer) and BS (Authenticator)
    MSK, AAA-Key as per eap-keying-draft
    PMK derived by truncation from AAA-Key.
    AK (Authentication Key) derived from PMK using a KDF(PMK, SS ID, BS,
ID)
    Two MACs (uplink and downlink) for signing the control messages
    One or more TEK (Traffic Encryption Keys) for encrypting user
traffic.
       These are derived from randoms by the BS and sent to MSS

MSK, AAA-Key are transported as per eap-keying-draft
PMK, AK, MACs are derived by peer and authenticator independently



>>
>>How are transient session keys derived?  How are they bound to the
correct
>>context?  How are authorization attributes handled?  Does this ensure
>>proper cryptographic binding?
>>
[<<sbakshi>>] These are defined in 802.16 specs. If people are
interested in getting an update on that, I will be glad to provide
material for that.



>>> BS does not implement any Authenticator functions.
>>
>>How do the parties identify themselves within the IEEE 802.16e
exchanges?
>>If the BS is not an authenticator, then the EAP peer cannot be aware
of
>>its identity;  that is, the BS must appear to be a port of the MSS,
and
>>the EAP peer can only be aware of the MSS identity in the layer below
EAP.
>>Is this how 802.16e works?
>> 
[<<sbakshi>>] Assuming I understood your question correctly. Upon
successful network entry (at PHY and MAC layer), MSS gets a connection
identifier that represent the connection to the BS and eap packet are
exchanged over this connection. So in my opinion for forwarding EAP
packets, BS does appear as a port to EAP-peer.



>>How does IEEE 802.16e negotiate the key lifetime of the MSK and TSKs?
Is
>>this done explicitly?  What meaning is ascribed to the RADIUS
Session-Time
>>attribute?

[<<sbakshi>>] Lifetime of MSK (derived from the eap session) is expected
to be exchange by RADIUS Session-Time attribute. There is no Security
Association protocol defined for lifetime management etc. of the
AAA-key. IMO equivalent to TSKs, 802.16e has TEKs (Traffic Encryption
Key) but 802.16e's current key derivation of TEKs does not follow the
guidelines mentioned in 1.3.3 of eap-keying-06. TEKs are derived as
randoms by BS and send to MSS encrypted and signed by keys derived from
PMK(AAA-Key)

>>
>>How are keys named in IEEE 802.16e?  How do the parties synchronize
the
>>key cache?  Are the messages within the Secure Association protocol
>>authenticated?
[<<sbakshi>>] 802.16e does not define anything analogous to Secure
Association protocol. Validity of AAA-Key in Authenticator and MSS is
assumed. There is a 3-way handshake to verify the liveliness of the
session key namely (AK) that is derived from AAA-key
>>_______________________________________________
>>eap mailing list
>>eap [at] frascone.com
>>http://mail.frascone.com/mailman/listinfo/eap