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

[Jari Arkko (jari.arkko]

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