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

[Jari Arkko (jari.arkko]

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