eap Mailing List: RE: Re: EAP key binding discussion

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Ok, I did sent an email about this, but it was too long and got clogged for 
approval. Here is a short version.

Basically the problem is how to use EAP key management framework to support 
handovers. In the current spec, after EAP is done, a AAA key is established 
between the peer and the AAA server and is pushed from the AAA server to the 
authenticator, so that the peer and authenticator can do a secure association 
protocol (say a 4-way exchange) to establish short term session keys.
Now if you want to support handovers, this would mean the peer now has to 
establish session keys with a new authenticator. If you want to make handover 
fast, you should not require a full EAP authentication, but should be able to 
use the same AAA key to derive session keys between the peer and new 
authenticator. To prevent domino effects and other attacks, it would make sense 
to not send the same AAA key to each and every authenticator. 

EAP keying draft 05 had a section describing derivation of per-authenticator 
AAA keys (lets call them AAABS key, BS for wireless base station). Say for 
simplicity this is how you derive the key for BS A and BS B.

AAABS-Key-A = prf(AAA key,"Per BS key derivation", BS-A-Id, Peer-Id,length)
AAABS-Key-B = prf(AAA key,"Per BS key derivation", BS-B-Id, Peer-Id,length)

This would allow hiding of AAA key from the BS, but would mean now we are 
sending AAABS-key to each authenticator. This seems to violate the EAP key 
management assumption of sending the AAA key to authenticator. Furthermore, the 
problem is that each base station would still have to get its key from the AAA 
server (too slow for handover).

Several alternatives to solve this problem have been suggested, including an 
EAP proxy by Sanjay:  So that the authenticator is placed between the BS and 
the AAA server and receives the AAA key, generates the AAABS key for each BS. 
Given that folks think there may be a bunch of binding problems with the EAP 
proxy approach and you need to find a protocol to run EAP over between BS and 
Authenticator, I am wondering if the following is acceptable:

What if we keep the 3-party model with each BS still acting as NAS, but when 
the EAP authentication is done, the AAA server sends the AAA key to another 
entity (such as local key distribution center, LKDC) instead.
 EAP peer                   BS/Authen        AAA server              LKDC
   --------                -------------   ------------               ------ 
    |                           |                  |                       |
    |<------------------------->|<---------------->|                       |
    |   EAP auth (phase 1a)     | AAA pass-thru    | --------------------->|    
                  
    |                           |                  | AAA-Key transport     |
    |                           | ---------------------------------------->|
    |                           |                  | AAABS-Key A request   |
    |                           | <----------------------------------------|
    |<------------------------->|         AAABS-key-A trans                |
    |  Secure assoc. protocol   |                  |                       |
    | (including a nonce exch.) |                  |                       |
    |                           |                  |                       |

To deal with RADIUS problems: The NAS can send the address for the LKDC to the 
AAA server during the initial EAP signaling and once the EAP success is 
received sends a message to the LKDC. The LKDC sends a access request to AAA 
server to receive the AAA key. 
LKDC would then be responsible to distribute AAABS key during handover or 
proactively to all BSs with a neighbor set.

Does this sound crazy?

Thanks in advance for comments.

Madjid


-----Original Message-----
From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
Behalf Of Nakhjiri Madjid-MNAKHJI1
Sent: Wednesday, April 27, 2005 3:00 PM
To: 'Bernard Aboba'; eap [at] frascone.com
Subject: FW: [eap] Re: EAP key binding discussion

Sorry for the late response to this. I have written something up. It is more a 
problem statement than a solution proposal. Basically because I was not sure 
whether sending the AAA key to some place other than an authenticator is 
against EAP key management principals.
I am sending this in the following email.

Regards,

Madjid


>Instead both the peer and EAP/ AAA server calculate a
>AAA-BS key that is bound to that base station. The EAP server only pushes
>the AAA-BS key to that BS (NAS). The AAA key to AAA-BS key is
>straightforward if you know the BS ID, peer ID and other things, as long
>as you know AAA key, of course, so the peer and AAA server both can do
>it. The handshakes happen based AAA-BS rather than AAA-key. But now, the
>BSs cannot derive the session keys for other BSs.

You are describing something which I don't believe is included in any of
the existing proposals.  If this is something that you're interested in
pursuing, the best way to go about it is to write a complete proposal for
how it would work, and then analyze it to see if conforms to the security
criteria in RFC 4017.  This would make it possible for the proposal to be
included in the EAP Key Management Extensions draft.

However, please understand that this is not something that is likely to be
completed in the 802.16e timeframe.
_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap