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

[Alper Yegin (alper.yegin]

Hi Dan,

Sorry for the latency in responding to your e-mail.

> I think much depends also where PAA resides, in AP/AR or deeper in the
> network.
> 
> If there are multiple PAAs (for example in each AP or AR), then the
AAAH
> can not have a security association with the every NAS (=PAA). It does
> not scale if the AAAH must serve all NASes in multiple networks
> (operator deployments for example).

In that case, most typically a AAA server in the visited network serves
the local NASes and has a direct (or indirect) security association with
the AAAH. This is how RADIUS deployments work today.

> This is one reason why we have also introduced another approach for
> pana-mobopts that leverages the AAA-Proxy model with an additional KDC
> similarly to 802.11r scenarios and also pana-cxtp.
> 
> http://www.ietf.org/internet-drafts/draft-forsberg-pana-skc-00.txt
> 
> This also fulfills the criteria.
> 
> Also, it's not a mobility optimization if the PaC needs to do full
> authentication after PAA change.

Upon optimized PANA authorization, the client is already allowed to
send/receive data packets. "In parallel with that", the network can also
force the client to run a fresh EAP authentication. I guess the text in
the I-D does not adequately capture this. 

Alper




> 
> Br,
> - Dan
> 
> 
> 
> >-----Original Message-----
> >From: eap-admin [at] lists.frascone.com
> >[mailto:eap-admin [at] lists.frascone.com] On Behalf Of ext Alper Yegin
> >Sent: 08 November, 2005 20:42
> >To: 'Russ Housley'
> >Cc: eap [at] frascone.com
> >Subject: RE: [eap] Re: questions on AAA key management draft
> >
> >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
> >
> >
> >_______________________________________________
> >eap mailing list
> >eap [at] lists.frascone.com
> >http://lists.frascone.com/mailman/listinfo/eap
> >