Subject: [Mip6] Summary of Justification for Alternative Authentication Option

From: Gopal Dommety <[email-masked]>
Date: Thu, 23 Sep 2004 14:55:05 -0700

Hello All,

             I am attaching a summary of the discussion that took place on
justification of an alternate authentication mechanism.  Please let me know if
I have left out any important issue in the summary. I could have also mis-read
people opinions, so if there is a correction please let me know. I will 
send a follow-up
  email with the next steps.

Thanks,
-Gopal

Summary
=======

The WG has been engaged in a discussion over the last week on the
topic of standardizing an authentication date suboption based
mechanism for the purpose of registering an MN with its HA via the
BU/BAck messages.
To summarize the discussion in brief:
1. The I-D draft-patil-mip6-whyauthdataoption-00.txt was used as the
    baseline for the discussion
2. Opinion was expressed that the I-D was more inclined in justifying
    why the use of  IKE was a problem for setting up the MN-HA IPsec SA
    and not really providing sufficient justifications for an
    alternative scheme to the use of IPsec for securing the signaling
    messages between the MN and HA
3. There were a few people who expressed strong views of keeping IPsec
    as the only means for MIP6 security between MN and HA (Francis and 
Hesham (?))
4. There were others who claimed the need for an alternate option to
    MIP6 including one operator who plans to deploy the protocol in
    their network (Raj, James Kempf, Alpesh, Gopal, Kuntal, Vijay, Michael Roe)
5. There was also a note from an implementers perspective on the
    challenges of integrating MIP6 with IPsec (Michael Roe)
6. There was discussion about the problem of replay attacks and the
    need for key refreshment
7. IKEv2 is expected to provide a solution to the problem of setting
    up dynamic SAs in networks that rely on AAA infrastructures. While
    IKEv2 itself has been approved, the details of how IKEv2 is used
    with MIP6 are still being worked out in an I-D that is not ready
    yet.
8. There was an opinion that the bootstrap work being done in the WG
    would address the needs of the environment claimed in I-D
    draft-patil-mip6-whyauthdataoption-00.txt

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 23 Sep 2004 16:44:32 -0700

hi Gopla,

there were a few coments on just using the AAA infrastructure
for creating security associations for IPsec. no IKE.

and there were also some concerns expressed on using both
authentication mechanisms at the same time.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Thu, 23 Sep 2004 22:49:27 -0700

Gopal,

I believe you missed the need for some mechanism to allow an MN to determine
which authentication technique to use. Without this, there is an
interoperability problem, because the MN cannot infer simply from the
failure of the signaling that it should try the other method.

            jak

----- Original Message ----- 
From: "Gopal Dommety" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 23, 2004 2:55 PM
Subject: [Mip6] Summary of Justification for Alternative
AuthenticationOption

---

From: Gopal Dommety <[email-masked]>
Date: Fri, 24 Sep 2004 10:38:24 -0700

James,

Would HA having to support both techniques be acceptable mechanism?

Thanks,
-Gopal

---

From: Francis Dupont <[email-masked]>
Date: Sun, 26 Sep 2004 19:27:03 +0200

In your previous mail you wrote:

   Summary
   =======

=> I believe "standardizing" means to make it a Proposed Standard,
doesn't it?

       their network (Raj, James Kempf, Alpesh, Gopal, Kuntal, Vijay,
       Michael Roe)

=> you should be more accurate: just alternate option or standardized
alternate option?

=> IMHO the main problem with an IKEv2 based solution is that there is
no public implementation... Another point is that IKEv2 does not support
home agent allocation.

=> some AAA/EAP based solutions are already ready (i.e., implemented)
and of course they support home agent allocation.

There are some other points:
 - we were supposed to ask an advice from security area directors
 - the requirement level of auth data option is still not clear enough
 - if the auth data option is only for the 3GPP2 environment there is
   no reason to standardize it at the IETF: the 3GPP2 can require what
   it wants in its own environment. If it likes to get an IETF document,
   an informational RFC should be enough and even faster (less possible
   concerns from the IESG).
Some of these points were already mentioned on the list...

Regards

[email-masked]

---

From: Gopal Dommety <[email-masked]>
Date: Sun, 26 Sep 2004 10:52:38 -0700

Francis,

please see inline...

>=> I believe "standardizing" means to make it a Proposed Standard,

Yes.