eap Mailing List: RE: Re: questions on AAA key management draft

[Alper Yegin (alper.yegin]

Hi Russ,

> >For instance it is not clear from the draft and its
> >  "prevention of Domino effect/ keying material confidentiality"
> >requirements whether
> >  context transfer of keying material from one authenticator to the
next
> >for support of fast mobility ruled out?
> 
> My going position is that this should not be allowed.  It would mean
> that the compromise of one authenticator has serious ramifications on
> other authenticators.  I am willing to listen to arguments to the
> contrary, but it will take a compelling argument to change my mind.

In PANA WG, we have a mobility optimization that relies on an anchor NAS
providing a session key to another NAS. Please see:

http://www.ietf.org/internet-drafts/draft-ietf-pana-mobopts-01.txt


Let me summarize it here using general terms:

NAS1 has already executed EAP with the client, and holds AAA-Key1. When
the client moves to NAS2, instead of running EAP again and generating a
new AAA-Key, this solution relies on NAS1 generating an
AAA-Key-int(erim) as follows:

AAA-Key-int = PRF(AAA-Key, NAS2-ID | Client-Session-ID)

NAS1 passes the AAA-Key-int to NAS2. NAS2 generates a new AAA-Key-new
as:

AAA-Key-new = PRF(AAA-Key-int, NAS2_nonce | client_nonce)


AAA-Key-new is used by the client and NAS2 until a new round of EAP
authentication is executed.

As we wrote in the security considerations section, compromise of NAS1
along with interception of nonces on the new link lead to compromise of
NAS2. But, compromise of NAS2 does not lead to compromise of NAS1. We
also suggested that for deployments that want to reduce the potential
threat should subsequently force the client to perform a new EAP
authentication with the NAS2.

We'd like to hear your thoughts on this. 

Given that this is an optional feature with a documented risk/warning
and a suggested remedy, do you still see issues with this?

Regards,

Alper