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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Jari,

Thank you for taking the time and responding. I agree with most of the things 
you said, but reading your last comments, I think I need to clarify myself. The 
NAS does not tell the AAA server that it is the LKDC. It simply informs the AAA 
server which LKDC it wants the key materials to be sent.
We need a midlevel in the hierarchy between AAA server and NAS to keep the 
AAA-key at, generate AAABS keys for each NAS, but keep the AAA-key from the NAS 
to prevent the domino effect.

                        AAA server
                        /       |   \
                  LKDC1   LKDC2  LKDC3
                  / |  \        /|\  /|\
            NAS1 NAS2 NAS3
 
Please note that in the suggested approach the KDCs are out of the EAP 
auth-path, which means the AAA server does not know where the KDC for a NAS and 
its neighbors are. That is why the NAS1 needs to send an AVP to AAA server 
including KDC1 ID (so AAA server does not have to keep NAS-KDC state and the 
network architecture can be flexible with load balancing).
The AAA server will send the AAA-key to a KDC only if it has a AAAserver-KDC SA 
to protect the AAA key.
For RADIUS we need a request/ response signaling started from KDC to get the 
AAA-key, which in turn means the NAS must send a trigger to the KDC (after EAP 
success possibly).
This way the round trip to AAA server is reduced to roundtrip to LKDC which can 
be collocated with local mobility manager.

All we are changing here is that we are saying "send the AAA key" to the KDC 
rather than to NAS. It is unconventional but is it less secure? I am not sure? 
It is more secure than just sending the AAA key to the first NAS.
But I appreciate all the help we can get with the threat analysis.

Madjid
-----Original Message-----
From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
Sent: Thursday, April 28, 2005 7:23 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Bernard Aboba'; eap [at] frascone.com
Subject: Re: [eap] Re: EAP key binding discussion

Thanks Madjid for describing the scenarios and possibilities!
Some comments below.

There appears to be multiple issues that we want to worry about
in the fast handoff case. We've discussed the domino effect; the
same key should not be usable more than in a single place.

Efficiency concerns might dictate that at least some lengthy authentication
procedure should not be repeated. Not sure if this fully applies
today, many EAP methods have support for fast reauthentication.

On the other, roundtrip concerns may still apply, particularly if
it is expected that the home AAA server is on the other side of
world.

Another issue is compatibility and deployment. The mechanisms
may require modifications at the access network, intermediate
AAA proxies or KDCs, or the home network. Changes to the home
network are in particular troublesome because you might need
to upgrade your AAA server just because someone is using a new
a roaming partner's new link layer with fast handoff support.

Protocol modifications are also an issue. Some things are easier
to add to RADIUS and Diameter than others. New AVPs are easy;
delivery to a new KDC might be harder. And how would we prevent
a NAS lying about being a KDC -- if we don't prevent this then we
are back to the domino effect. Or maybe not, but at the
moment I at least don't see all the impacts at the system level well
enough.

Some of these requirements may also be contradictory, so we
may need to select which ones we care most for...

--Jari

Nakhjiri Madjid-MNAKHJI1 wrote:

>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
>_______________________________________________
>eap mailing list
>eap [at] frascone.com
>http://mail.frascone.com/mailman/listinfo/eap
>
>
>  
>