eap Mailing List: RE: Re: AMSKs for MIPv6

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Avi, Thanks for the description.

-----Original Message-----
From: eap-admin [at] lists.frascone.com [mailto:eap-admin [at] 
lists.frascone.com]
On Behalf Of Avi Lior
Sent: Thursday, November 03, 2005 8:44 PM
To: Bernard Aboba; eap [at] frascone.com
Subject: RE: [eap] Re: AMSKs for MIPv6

Hi Bernard, 

> -----Original Message-----
> From: eap-admin [at] lists.frascone.com
> [mailto:eap-admin [at] lists.frascone.com] On Behalf Of Bernard Aboba
> Sent: Thursday, November 03, 2005 8:46 PM
> To: eap [at] frascone.com
> Subject: [eap] Re: AMSKs for MIPv6
> 
> >MN <------> HA <-------> AAA
> 
> >So we'll need exchange between MN and HA and between HA and AAA.

No.  There is an EAP exchange between the MN and the AAA.

So the call flow looks like this:

MN       NAS        HA        AAA
           Access Request (EAP)
 +++++++++--------------------->                Normal EAP
Authentication
           Access Accept (EAP Success + keys)
 +++++++++<---------------------
 
 MIPv6 Binding Update
 ====================>   Access Request
                      ---------->
                         Access Accept
 MIPv6 Binding Answer <----------
<=====================

As shown above we do normal EAP based access request. 

The NAS is the authenticator.

When that is completed, the MN performs a MIPv6 Binding Update.

The HA receives the BU and because it doesn't know the MN it uses the
NAI and consults with the AAA server.

We would like to use the EAP keys or Keys derived from the EAP for the
MIPv6 part.



> Is an EAP exchange being run between the MN and AAA server, with the 
> HA serving as the "EAP authenticator"?  If so, the end result of this 
> exchange is that the MN, HA and AAA server share a key.
> 
> >The EAP peer and server derive MSK and EMSK. The AAA server
> requests to
> >the EAP server an 'AMSK for Mobile IPv6'.
> >
> >A mobility management entity (not the EAP lower layer) on the mobile 
> >node requests locally the 'AMSK for Mobile IPv6' to the EAP layer.
> 
> Assuming that the HA is acting as an "EAP authenticator" 
> here, the end result of this is that the MN and the EAP server/AAA 
> server now have mutually authenticated to each other and have derived 
> an AMSK that they know
> is fresh, and which is known only to them.   The HA and AAA 
> server now
> mutually authenticate and derive a cryptographically secure channel.  
> The AMSK is now transported to the HA, which can use it in a mutual 
> proof of possession exchange with the MN.
> 
> >Then, if we want that the mobile node shares a key with the HA, this 
> >implies that the HA requests a key to the AAA server.
> 
> Before the HA can request a key from the AAA server, it needs to prove

> that
> it is authorized to receive that key.   Typically this 
> requires that it
> mutually authenticate to the AAA server *and* include some "proof of 
> liveness" from the EAP peer to show that the peer is actually 
> interested in communicating with it.
> 
> So a better way to think about this is that the HA is not really 
> requesting a key -- it is the EAP peer that is requesting that the AAA

> Server send a
> key to that specific HA.   If the EAP peer and AAA server 
> share a trust
> relationship and are mutuall authenticated, and if the HA and AAA 
> server are mutually authenticated, and if the key that is being 
> requested is unambiguously specified (e.g. it is "named"), then the 
> AAA server will authorize the request and transport the key to the HA.
> 
> >I stay vague here. But one can imagine that the 'AMSK for
> Mobile IPv6'
> >is used by the MN to authenticate himself to the AAA.
> 
> "Key Request" proposals typically require mutual authentication 
> between the EAP peer and AAA server.  For example, if the MN/peer had 
> previously established a cached AMSK with the AAA server, it can 
> subsequently prove possession of that AMSK, and ask that a key derived

> from that AMSK be sent
> to an HA that it specifies.   This request needs to be 
> "routed" through the
> HA itself, which mutually authenticates to the AAA server.  
> This guarantees that the "Key Request" is authenticated, bound to the 
> entities involved in the exchange, and can generate fresh keys (this 
> part probably requires nonces to be exchanged by the parties).
> 
> >This pre-shared key will be derived at MN and AAA from the "AMSK for 
> >Mobile IPv6" and then transported from the AAA to the HA.
> 
> If the key is dynamically derived it is not a pre-shared key.
> 
> >SO the 'AMSK for Mobile IPv6' is cached on the AAA server and MN but 
> >not transported. The key derived for MN-HA is deleted on the AAA and 
> >transported to the HA.
> 
> Right.
> 
> >Does such a mechanism seem correct respective to EAP keying
> framework ?
> 
> It seems compatible with the "Key Request" extension that has been 
> discussed.
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] lists.frascone.com
> http://lists.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
eap [at] lists.frascone.com
http://lists.frascone.com/mailman/listinfo/eap