Subject: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2)

From: Julien Bournelle <[email-masked]>
Date: Fri, 15 Sep 2006 12:21:14 +0200

Hi all,

 this is a new polling concerning the ha-aaah interface for the Mobile
 IPv6 Boostrapping. To date, at the previous one, there was a
 consensus on moving forward with a new App-ID. But, yoshi has
 proposed an interesting idea that should be considered by the WG.

 As you may recall, in the ha-aaah case, the MN is authenticated by
 EAP (IKEv2 is used between MN and the HA) and thus the HA-AAAH
 interface must, at least, be able to carry EAP packets. It appears that
 we now have 2 options:

 (1) We define a new Diameter application for Mobile IPv6 with a new
     App-ID that carry EAP packets as it is done in RFC 4072 (Diameter
     EAP) but Authorization and Accouting is specific to Mobile IPv6
     (thus the need for a new App-ID). The risk, as noted by yoshi, is
     that an update of the RFC4072 may result in an update of this
     application. 

 (2) We define a new Diameter Application for Mobile IPv6 but which is
     used for Authorization and Accounting. We continue to use
     Diameter EAP for the Authentication. Thus the HA will use
     Diameter EAP with the AVP Auth-Request-Type set to
     AUTHENTICATE_ONLY and then the HA will use this MIP6 Application
     for Authorization/Accounting of the Mobile IPv6 service. This new
     application will have its own App-ID.

     This would avoid to update the application if 4072 is updated and
     this could be a way to proceed if other applications need EAP for
     Authentication but have different needs for the Authorization and
     Accounting part.

 Please indicate wether you prefer (1) or (2).  

 As in the previous polling:
 - it might be useful to state a reason for your decision. 
 - indicate wether some aspects are still unclear to you.

 Regards,

 Julien

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 15 Sep 2006 10:35:59 -0700

Julien Bournelle wrote:
>  interface must, at least, be able to carry EAP packets. 

there was never an intention to restrict HA-AAAH interface to EAP
only. other mechanisms are possible. using EAP over IKEv2 is just
one way of using the AAA for the HA to authenticate a mobile node.

Vijay

It appears that

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 15 Sep 2006 18:03:57 -0700

I agree with Vijay.

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Friday, September 15, 2006 10:36 AM
To: Julien Bournelle
Cc: [email-masked]
Subject: Re: [Dime] HA-AAAH case: App-ID vs (4072 + App-ID) (polling part 2)

Vijay

It appears that

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 17 Sep 2006 02:57:56 -0400

Thank you for taking a new poll.  I am in favor of option 2.

Let me note that option 2 can also work for:

- HA-AAAH case where non-EAP authentication is used for the
authentication part.

- NAS-AAAH case (I am not sure there is already a consensus on a
solution for NAS-AAAH case).  Again not only EAP but also non-EAP
authentication application can be used for the authentication part.  A
difference from the HA-AAAH case is that Auth-Request-Type AVP of the
authentication application would be set to AUTHORIZE_AUTHENTICATE in
the NAS-AAAH case because network access service should be provided if
authentication succeeds regardless of MIP6 service.

Regards,
Yoshihiro Ohba

---

From: <[email-masked]>
Date: Mon, 18 Sep 2006 05:23:58 +0300

Vijay,

>there was never an intention to restrict HA-AAAH interface to 
>EAP only. other mechanisms are possible. using EAP over IKEv2 
>is just one way of using the AAA for the HA to authenticate a 
>mobile node.

I think Julien is suggesting that EAP could be the minimum requirement,
but not restricting the solution to EAP.  

Do you have a general opinion on any of the options that Julien is
asking?

John