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

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 2 May 2005 02:58:07 -0500

Hi Bernard,

I guess I may need to look at your performance data for 802.11. Not sure if that applies universally for a general wireless link, though. However, You ARE referring to WLAN switches, not sure how the switch is architected with respect to the AAA server and the AP and who acts as the authenticator? And how the key distribution is handled? Do you care to share some insights on that or that is proprietary.

Madjid

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, April 28, 2005 12:50 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: RE: FW: [eap] Re: EAP key binding discussion

> What about disclosure of the keys between the authenticators??

Here is the requirement (from RFC 4017):

      Requirement: "Compromise of a single authenticator cannot
      compromise any other part of the system, including session keys
      and long-term secrets."

"any other part of the system" would seem to include other authenticators.

> I think EAP and its key management framework has not positioned itself
> well with respect to handovers and that is why the door for interpretations
> is being opened over and over.

I'd be interested in any data that you have collected on this.  Having
recently done some tests on handover times in WLAN switches, I was
surprised by how well the equipment performs.  For example, we have
measured handoffs of 25ms or less on a consistent basis with a number of
WLAN switch products.  These measurements were made on equipment implementing
RFC 3579, RFC 3748, and WPA2 (including pre-authentication).

I have collected published material on handoff times at the following
location:
http://www.drizzle.com/~aboba/IEEE/

> the "mutual authentication" condition which requires mutual
> authentication between all parties,
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 May 2005 16:53:50 +0300

Hi Madjid,

>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.
>  
>
Hmm... security-wise there might not be a big difference, if
you can send keys to an entity that is in the attacker's control.

But a lot depends on exactly how the kdc would be used. If
the server has been configured with the identifiers of the
NASes that a supported by a particular kdc, then its not an
issue. But this seems hard to achieve in practise.

>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.
>
Yes, I've been wondering about that. Keeping the KDC out of path
appears to create additional issues in terms of finding it using
existing AAA protocols, possibly more roundtrips. The other
alternative would be to use existing proxies for a new purpose.
This may be undesirable too, for other purposes.

>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.
>  
>
What kind of AAAServer-KDC SA are we talking about? Are we expecting
this to work in a roaming scenario? Does isp1.fi need to get a SA with
access2.ca KDC before users can roam there, above and beyond what
has already been set up for other AAA transactions?

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