Re: [Mip6] Summary of Justification for AlternativeAuthenticationOption

Gopal Dommety <gdommety@cisco.com> Sun, 26 September 2004 17:54 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20917 for <mip6-web-archive@ietf.org>; Sun, 26 Sep 2004 13:54:34 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBdLl-00055y-F6 for mip6-web-archive@ietf.org; Sun, 26 Sep 2004 14:02:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBdB5-0002Q9-KC; Sun, 26 Sep 2004 13:51:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBdAB-0002I5-GF for mip6@megatron.ietf.org; Sun, 26 Sep 2004 13:50:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20796 for <mip6@ietf.org>; Sun, 26 Sep 2004 13:50:18 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CBdHd-00051H-QJ for mip6@ietf.org; Sun, 26 Sep 2004 13:58:02 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Sep 2004 11:02:44 +0000
X-BrightmailFiltered: true
Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8QHnflr001366; Sun, 26 Sep 2004 10:49:42 -0700 (PDT)
Received: from gdommety-w2k04.cisco.com (sjc-vpn4-903.cisco.com [10.21.83.134]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AEQ89337; Sun, 26 Sep 2004 10:49:42 -0700 (PDT)
Message-Id: <4.3.2.7.2.20040926104610.02c04d18@mira-sjc5-d.cisco.com>
X-Sender: gdommety@mira-sjc5-d.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 26 Sep 2004 10:49:43 -0700
To: James Kempf <kempf@docomolabs-usa.com>
From: Gopal Dommety <gdommety@cisco.com>
Subject: Re: [Mip6] Summary of Justification for AlternativeAuthenticationOption
In-Reply-To: <004401c4a2db$6c3e0d40$576015ac@dcml.docomolabsusa.com>
References: <697DAA22C5004B4596E033803A7CEF4403B1BE7C@daebe007.americas.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d

James,



>I hope that makes my position clearer. I hope, in the future, that the WG
>chairs will strive to be a little more accurate and objective when
>performing concensus calls.

The email I sent out was a summary of the discussion and not a summary of 
the consensus call. Next time I will be strive to be clearer.

Thanks,
-Gopal




>             jak
>
>----- Original Message -----
>From: <Basavaraj.Patil@nokia.com>
>To: <kempf@docomolabs-usa.com>; <mip6@ietf.org>; <gdommety@cisco.com>
>Sent: Friday, September 24, 2004 8:51 AM
>Subject: RE: [Mip6] Summary of Justification for
>AlternativeAuthenticationOption
>
>
>
>James,
>
>I disagree with the need for having such a mechanism in view of the fact
>that an HA is expected to support both the authentication schemes
>mandatorily.
>
>-BPa
>
> >
> > 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" <gdommety@cisco.com>
> > To: <mip6@ietf.org>
> > Sent: Thursday, September 23, 2004 2:55 PM
> > Subject: [Mip6] Summary of Justification for Alternative
> > AuthenticationOption
> >
> >
> > > 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
> > > Mip6@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/mip6
> > >
> >
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > Mip6@ietf.org
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
>
>
>
>_______________________________________________
>Mip6 mailing list
>Mip6@ietf.org
>https://www1.ietf.org/mailman/listinfo/mip6


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6