IETF Logo Mail Archive

Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01

"Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com> Tue, 28 July 2009 09:13 UTC

Return-Path: <dirk.kroeselberg@nsn.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F9C3A6B26 for <mext@core3.amsl.com>; Tue, 28 Jul 2009 02:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rckPZ6j44nkT for <mext@core3.amsl.com>; Tue, 28 Jul 2009 02:13:06 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4624A3A6D91 for <mext@ietf.org>; Tue, 28 Jul 2009 02:13:06 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6S9D6eU003800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2009 11:13:06 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6S9D4IE025113; Tue, 28 Jul 2009 11:13:05 +0200
Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:13:04 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Jul 2009 11:13:03 +0200
Message-ID: <8C51C7A529FC9D49843ACF5AE2FFBF67019F6414@DEMUEXC030.nsn-intra.net>
In-Reply-To: <87ocr56vbo.fsf@small.ssi.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: AW: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01
Thread-Index: AcoPYQlZ6jWkQaSdTr2J8nkZ1/iKgwAALVAA
References: <C68F84FA.2B9FF%basavaraj.patil@nokia.com><87tz0xkjps.fsf@small.ssi.corp><9F72E813-4169-44E4-BA07-D70DC1C7070C@gmail.com><871vo18ccf.fsf@small.ssi.corp><8C51C7A529FC9D49843ACF5AE2FFBF67019CB73E@DEMUEXC030.nsn-intra.net> <87ocr56vbo.fsf@small.ssi.corp>
From: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com>
To: Arnaud Ebalard <arno@natisbad.org>
X-OriginalArrivalTime: 28 Jul 2009 09:13:04.0274 (UTC) FILETIME=[9CF19F20:01CA0F63]
Cc: jouni korhonen <jouni.nospam@gmail.com>, Basavaraj.Patil@nokia.com, mext@ietf.org
Subject: Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2009 09:13:07 -0000

Hi Arnaud,  

> -----Original Message-----
> From: Arnaud Ebalard [mailto:arno@natisbad.org] 
> Sent: Tuesday, July 28, 2009 10:55 AM
> To: Kroeselberg, Dirk (NSN - DE/Munich)
> Cc: jouni korhonen; mext@ietf.org; Basavaraj.Patil@nokia.com
> Subject: Re: AW: [MEXT] Review of draft 
> draft-patil-mext-mip6issueswithipsec-01
> 
> Hi,
> 
> "Kroeselberg, Dirk (NSN - DE/Munich)" 
> <dirk.kroeselberg@nsn.com> writes:
> 
> >> > [snip] relying on TLS (or even DTLS) for MIPv6 is IMHO a 
> bad design
> >> > idea.
> >> >
> >> > Looks bad why? Please, list the points that lead to this 
> >> conclusion. I
> >> > would help us greatly.
> >> 
> >> - Because TLS has been designed to secure transport streams ..
> >> - ... not as a key exchange mechanism for L3
> >
> > Would there be any technical problem with this?
> 
> I should have written key provisioning. Anyway, I don't think there is
> any *technical* problem with this apart from changing the initial
> purpose of the protocol. The comment was meant to be generic,
> i.e. against trying to do X at layer Y with a protocol that has been
> done to do Z at layer W.

I agree with the general comment. But it is always a problem to do such
thing. 

You can also see it as just establishing a TLS-secured tunnel and some
other http based 'key provisioning' scheme can be run through this
tunnel (I think this is the idea of the current draft). The advantage of
this is that other http-based exchanges than the default one can easily
be plugged in. TLS just secures the transport. Of course this requires
to look at stuff like man-in-the-middle attacks.
 
> 
> > With EAP-TLS that you are mentioning below, TLS does the same thing
> > for L2.   
> 
> Yes, that's the reason I wonder why the draft doesn't use the same
> scheme instead of creating a new one, i.e. it doesn't reuse the
> *derived* key material instead of having the HAC push it over https.
> There may be reasons but they are not discussed.

See above.

> 
> Cheers,
> 
> a+
>

v2.23.0 | Report a Bug | By Email