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

[Dan.Forsberg (Dan.Forsberg]

Alper and Russ,

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

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.

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
>