Subject: RE: [eap] Re: EAP key binding discussion

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 27 Apr 2005 20:43:03 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Nakhjiri Madjid-MNAKHJI1
Sent: Wednesday, April 27, 2005 3:00 PM
To: 'Bernard Aboba'; [email-masked]
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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Apr 2005 15:22:40 +0300

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 28 Apr 2005 16:10:37 +0200

Hi Nakhjiri

After I read this, I think it seems to be similar to PANA when PAA is 
not colocated in the EP for example in the wireless LAN 
model(http://www.ietf.org/internet-drafts/draft-ietf-pana-framework-03.txt). 

In fact PaC/EAP peer can derive one PMK per each EP/AP controlled by 
PAA.  PAA can derive the same keys that would send to different EPs 
controlled by this PAA (how to derive PMKs per each EP/AP derived from 
AAA-key that PAA receives  from AAA is ongoing work). So PAA would be 
like your LKDC. However PAA is also acting as NAS that 
is a difference what you propose.

On the other hand , when a EAP peer moves to another EP/AP controlled by 
another LKDC then we are moving the problem to allow a fast handoff 
between LKDCs. In the case of PANA , it is being treated in 
http://www.ietf.org/internet-drafts/draft-bournelle-pana-ctp-02.txt and 
http://www.ietf.org/internet-drafts/draft-ietf-pana-mobopts-00.txt

Only FYI (extracted from draft-ietf-pana-framework-03.txt)

"1.  The PaC associates with the AP.

  2.  The PaC configures a PRPA by using DHCP (in the case of IPv4) or
      configures a link-local address (in the case of IPv6), and then
      runs PANA.

 ----> 3.  Upon successful authentication, the PaC obtains a separate 
PMK for each AP controlled by the PAA.<---------

  4.  The AP initiates IEEE 802.11i 4-way handshake to establish a PTK
      (Pair-wise Transient Key) with the PaC, by using the PMK.

  5.  The PaC obtains a POPA by using any method that the client
      normally uses."

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------