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

Vijay Devarapalli <vijayd@iprg.nokia.com> Thu, 23 September 2004 23:38 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 TAA05391 for <mip6-web-archive@ietf.org>; Thu, 23 Sep 2004 19:38:56 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAdHq-0005Ay-Ps for mip6-web-archive@ietf.org; Thu, 23 Sep 2004 19:46:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAd9D-0002fW-EB; Thu, 23 Sep 2004 19:37:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAd5l-00028p-1i for mip6@megatron.ietf.org; Thu, 23 Sep 2004 19:33:38 -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 TAA05073 for <mip6@ietf.org>; Thu, 23 Sep 2004 19:33:33 -0400 (EDT)
Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAdCc-00054O-BD for mip6@ietf.org; Thu, 23 Sep 2004 19:40:43 -0400
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i8NN61j01628; Thu, 23 Sep 2004 16:06:01 -0700
X-mProtect: <200409232306> Nokia Silicon Valley Messaging Protection
Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdT3YHCf; Thu, 23 Sep 2004 16:05:59 PDT
Message-ID: <41535FE0.8040600@iprg.nokia.com>
Date: Thu, 23 Sep 2004 16:44:32 -0700
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gopal Dommety <gdommety@cisco.com>
Subject: Re: [Mip6] Summary of Justification for Alternative Authentication Option
References: <4.3.2.7.2.20040923143829.029e1a48@mira-sjc5-d.cisco.com>
In-Reply-To: <4.3.2.7.2.20040923143829.029e1a48@mira-sjc5-d.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: 7bit
Cc: mip6@ietf.org
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: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: 7bit

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

Gopal Dommety wrote:
> 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