Subject: RE: [eap] Re: AMSKs for MIPv6

From: "Avi Lior" <[email-masked]>
Date: Thu, 3 Nov 2005 21:43:38 -0500

Hi Bernard, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, November 03, 2005 8:46 PM
> To: [email-masked]
> 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
> [email-masked]
> http://lists.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap

---

From: Gerardo Giaretta <[email-masked]>
Date: Fri, 04 Nov 2005 09:28:54 +0100

Hi Avi, Bernard, all 

what we have been discussing in the MIP6 bootstrapping DT is slightly
different. Please see my comments below..

>            Access Accept (EAP Success + keys)

So far it is correct.

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

Before performing a MIPv6 BU, the MN must set up an IPsec SA with the
HA. 

In the DT we are thinking that an AMSK (or a key derived from the AMSK)
may be used as the pre-shared key in the IKE_AUTH exchange between MN
and HA. The AAA server should send this key to the HA before the MN gets
in touch with the HA. As far as I understand from Bernard's comments,
this is ok if the MN/EAP peer requests the AAA server to perform the key
delivery and if HA and AAA server are mutually authenticated. Please
correct me if I'm wrong.

A different approach may be the following (pull approach): the MN starts
IKE_AUTH with the AMSK as the pre-shared key. During IKEv2 exchange the
HA requests the key to AAA server. If I understand correctly from
Bernard comment, this is not possible based on EAP keying.

> NAI and consults with the AAA server.

This MAY be possible if mip6-auth option is used. If IPsec is used to
authenticate BUs this is not correct.

> We would like to use the EAP keys or Keys derived from the EAP for the

(DT leader hat on)

Just a bit of history: in the bootstrapping DT we have addressed two
scenarios, the split scenario and the integrated scenario. In the
integrated scenario the entity that authenticates and authorizes the MN
for network access service and the entity that authenticates and
authorizes the MN for MIPv6 service are the same. This implies that the
MIPv6 bootstrapping procedure may be optimized (e.g. in terms of round
trips) if the outcome of the authentication for network access is used
also for mobility service. The usage of an AMSK for MIPv6 is one
possible approach to achieve that.
Currently the DT has not produced any draft on this since we are waiting
for a normative reference for AMSK and we would like having some
feedback from EAP WG. 

(DT leader hat off)

An old draft (expired) about this is
http://www-lor.int-evry.fr/~maknavic/DRAFT/draft-giaretta-mip6-amsk-00.t
xt. 

Thanks,
--Gerardo 

> > It seems compatible with the "Key Request" extension that has 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================
_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Avi Lior" <[email-masked]>
Date: Fri, 4 Nov 2005 04:08:36 -0500

Hi Gerardo and Bernard

Please note (as Gerardo elludes to) that there are two ways to perform
authentication of BU in MIPv6 one is using Ipsec and the other is using
the BU authentication procedure defined in the
draft-ietf-mip6-auth-protocol-08.txt, which does not use Ipsec at all
but rather a scheme of authenticating the BU similar to that used in
MIPv4.

The point I or we wanted to make to Bernard is that the MIPv6
Authentication happens *after* the EAP authentication, and specifically:
-The HA is not involved in the EAP authentication; and
-The NAS, which is involved in the EAP authentication, is not involved
in the MIPv6 authentication.

Your description speaks to the Ipsec method where as my description was
sufficient to describe the the non-Ipsec method. 

So we need to understand these two models for MIPv6 authentication.

In the non-Ipsec model after EAP based access authentication, the HA
receives a BU from some MN. Not having seen this MN before, it consults
a AAA server using the NAI contained in the BU in order to authenticate
the BU.

So the question is, can we use keys derived from EAP to perform this
operation? Which keys? 

> From: Gerardo Giaretta [mailto:[email-masked]] 
> Sent: Friday, November 04, 2005 3:29 AM
> To: Avi Lior; Bernard Aboba; [email-masked]
> Subject: RE: [eap] Re: AMSKs for MIPv6
> 
> Hi Avi, Bernard, all 
> 
> what we have been discussing in the MIP6 bootstrapping DT is 
> slightly different. Please see my comments below..
> 
> > > 

> Before performing a MIPv6 BU, the MN must set up an IPsec SA 
> with the HA. 
> 
> In the DT we are thinking that an AMSK (or a key derived from 
> the AMSK) may be used as the pre-shared key in the IKE_AUTH 
> exchange between MN and HA. The AAA server should send this 
> key to the HA before the MN gets in touch with the HA. As far 
> as I understand from Bernard's comments, this is ok if the 
> MN/EAP peer requests the AAA server to perform the key 
> delivery and if HA and AAA server are mutually authenticated. 
> Please correct me if I'm wrong.

> 
> A different approach may be the following (pull approach): 
> the MN starts IKE_AUTH with the AMSK as the pre-shared key. 
> During IKEv2 exchange the HA requests the key to AAA server. 
> If I understand correctly from Bernard comment, this is not 
> possible based on EAP keying.

> This MAY be possible if mip6-auth option is used. If IPsec is 
> used to authenticate BUs this is not correct.

Remind me please why this is not possible using IPsec?

> Just a bit of history: in the bootstrapping DT we have 
> addressed two scenarios, the split scenario and the 
> integrated scenario. In the integrated scenario the entity 
> that authenticates and authorizes the MN for network access 
> service and the entity that authenticates and authorizes the 
> MN for MIPv6 service are the same. This implies that the
> trips) if the outcome of the authentication for network 
> access is used also for mobility service. The usage of an 
> AMSK for MIPv6 is one possible approach to achieve that.
> Currently the DT has not produced any draft on this since we 
> are waiting for a normative reference for AMSK and we would 
> like having some feedback from EAP WG. 
> 
> (DT leader hat off)
> 
> > > 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.
> > > 
> server/AAA 
> > > server now have mutually authenticated to each other and have 
> > > derived an AMSK that they know
> > > 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.
> > > 
> > > Before the HA can request a key from the AAA server, it needs to 
> > > prove that
> > > 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
> > > 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.
> > > 
> > > "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
> > > 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).
> > > 
> > > It seems compatible with the "Key Request" extension that 
> has been 
> > > discussed.
> > > 
> > > 
> This message and its attachments are addressed solely to the 
> persons above and may contain confidential information. If 
> you have received the message in error, be informed that any 
> use of the content hereof is prohibited. Please return it 
> immediately to the sender and delete the message. Should you 
> have any questions, please send an e_mail to

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Fri, 4 Nov 2005 16:26:20 -0500

Avi, Thanks for the description.

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

Hi Bernard, 

MN       NAS        HA        AAA
           Access Request (EAP)
 
 MIPv6 Binding Update

> 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.
> 
> 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
> mutually authenticate and derive a cryptographically secure channel.  
> The AMSK is now transported to the HA, which can use it in a mutual 
> Before the HA can request a key from the AAA server, it needs to prove

> that
> mutually authenticate to the AAA server *and* include some "proof of 
> requesting a key -- it is the EAP peer that is requesting that the AAA

> Server send a
> requested is unambiguously specified (e.g. it is "named"), then the 
> AAA server will authorize the request and transport the key to the HA.
> 
> 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
> 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).
> 
> It seems compatible with the "Key Request" extension that has been 
> discussed.
> 
>