Subject: RE: [eap] Re: questions on AAA key management draft

From: <[email-masked]>
Date: Thu, 10 Nov 2005 12:46:08 +0200

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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Alper Yegin
>Sent: 08 November, 2005 20:42
>To: 'Russ Housley'
>Cc: [email-masked]
>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
>[email-masked]
>http://lists.frascone.com/mailman/listinfo/eap
>
_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 21 Nov 2005 00:23:39 +0200

Hi Dan,

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

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

> 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

> >risk/warning and a suggested remedy, do you still see issues with
this?

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org