IETF Logo Mail Archive

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

arno@natisbad.org (Arnaud Ebalard) Tue, 28 July 2009 08:54 UTC

Return-Path: <arno@natisbad.org>
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 61AF73A6DA6 for <mext@core3.amsl.com>; Tue, 28 Jul 2009 01:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.558
X-Spam-Level:
X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 HOrFf+YoxJCS for <mext@core3.amsl.com>; Tue, 28 Jul 2009 01:54:34 -0700 (PDT)
Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 21D2B3A6D37 for <mext@ietf.org>; Tue, 28 Jul 2009 01:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:References:Date: In-Reply-To:Message-ID:MIME-Version:Content-Type; bh=5CfIIunJOWv Uuz5g1utGiM+f5MHEua6CQV0v0ZTs8jo=; b=iayON5TIcD4QwwnKmd4/A0iIrly SAtZzlWaSZyQXqzAcHdOKezXN1zfVdefnF3trbgYBkVnmKNxzDv4Ej1TkusldAiM H9O97k0+walAzEbelcsflQ59tgxRZPXKDjIfWuLsdPYeUeiwbLiMB8xtOx93Fbbv NrKG+P1pQghKz1fI=
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <arno@natisbad.org>) id 1MViS7-0001zl-6g; Tue, 28 Jul 2009 10:54:31 +0200
From: arno@natisbad.org
To: "Kroeselberg, Dirk (NSN - DE/Munich)" <dirk.kroeselberg@nsn.com>
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>
X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc
X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026
X-Hashcash: 1:20:090728:mext@ietf.org::htPgRtwUWfw153sZ:00000P/j
X-Hashcash: 1:20:090728:basavaraj.patil@nokia.com::9HGQ9x5uGZEr/mTI:0000000000000000000000000000000000000Qvg
X-Hashcash: 1:20:090728:dirk.kroeselberg@nsn.com::bRVwxhVumdASTnUk:00000000000000000000000000000000000001/P7
X-Hashcash: 1:20:090728:jouni.nospam@gmail.com::q1QRKm1thsPj0D5J:0000000000000000000000000000000000000002NbN
Date: Tue, 28 Jul 2009 10:55:07 +0200
In-Reply-To: <8C51C7A529FC9D49843ACF5AE2FFBF67019CB73E@DEMUEXC030.nsn-intra.net> (Dirk Kroeselberg's message of "Tue, 28 Jul 2009 10:23:54 +0200")
Message-ID: <87ocr56vbo.fsf@small.ssi.corp>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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 08:54:35 -0000

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.

> 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.

Cheers,

a+

v2.23.0 | Report a Bug | By Email