Subject: RE: [Mip6] Concerning mip6 auth. and conf. based on EAP

From: Giaretta Gerardo <[email-masked]>
Date: Fri, 13 Feb 2004 19:22:00 +0100

Hi Mayumi,

thanks for your feedback. See below for my answers...
 
> 
> - It is specified that AAAH send cryptographic material to MN.
>   I think it is not necessary, when Pre-shared Key based 
> authentication
>   is applied to establish ISAKMP SA.
>   Because AAA and MN can share symmetric key, EAP Key, during access
>   authentication. And AAA and MN also can derive symmetric key from
>   the shared key.
>   It is specified in "draft-salowey-eap-key-deriv-02.txt".
>   We proposed an architecture which use EAP key as service
>   authentication.<draft-yanagiya-eap-saa-00.txt>
>   And we are going to submit revised draft which includes a method
>   that applied the above concept to establish SA between HA and MN.
>

As we have written in the Open Issues section of our draft, we think that deriving the pre-shared key exploiting the EAP Key Management Framework is a good approach and it might improve the security of the architecture. We are still working on this solution. I've read draft-yanagiya-eap-saa-00.txt: I think that the solution described is really generic and for this reason I'm waiting for next version, more MIPv6-related.

Moreover, a better approach would be using the AAA infrastructure to establish the ISAKMP or the IPsec SA: this approach would reduce the number of IKE RTTs needed or totally avoid the IKE negotiation...

> - You used “AAA” and “AAAH” as authentication server.
>   Is it a spelling mistake or not?

By AAAH we mean the AAA server of the Home Provider, while by AAA we mean a generic AAA server.

> 
> - In actual public service network, I think it is difficult that
>   AAAH selects proper HA in visited network.  So, I think
>    -AAAH authenticates MN, and
>    -AAA in visited network selects proper HA and distributes
>     cryptographic material
>   Would you mind giving comments to this idea?
> 

In Appendix A we have described the procedure to allocate a Home Agent in the foreign domain. As depicted in figure 13, AAAH (AAA server of the home provider) communicates with AAAF (AAA server of the foreign provider) to allocate the Home Agent: however, note that the HA and the cryptogrphic material are selected by the AAAF and not by the AAAH. Then, AAAF sends these data to AAAH through a Foreign-Home-Agent-Answer message and the AAAH sends the data to the MN via EAP-TLVs. Obviously, we are assuming that AAAH and AAAF share a security association.

Regards,
--Gerardo

====================================================================
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 contact us by
replying to [email-masked]. Thank you
====================================================================

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: Alper Yegin <[email-masked]>
Date: Fri, 13 Feb 2004 11:25:12 -0800

> As we have written in the Open Issues section of our draft, we think that
> deriving the pre-shared key exploiting the EAP Key Management Framework is a
> good approach and it might improve the security of the architecture.

We are solving a somewhat similar problem by using EAP-based keys. Please
see draft-yegin-eap-boot-rfc3118-00.txt. This is the extended version of
draft-tschofenig-pana-bootstrap-rfc3118-00.txt.

FYI...

Alper