Re: [dhcwg] on use case discussion for draft-ietf-dhc-sedhcpv6

Ted Lemon <Ted.Lemon@nominum.com> Wed, 25 February 2015 19:30 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE7F1A700A for <dhcwg@ietfa.amsl.com>; Wed, 25 Feb 2015 11:30:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpnBvHpOQ89q for <dhcwg@ietfa.amsl.com>; Wed, 25 Feb 2015 11:30:44 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66971A1EB7 for <dhcwg@ietf.org>; Wed, 25 Feb 2015 11:30:44 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 9BCA6DA01F2 for <dhcwg@ietf.org>; Wed, 25 Feb 2015 19:30:44 +0000 (UTC)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 7225053E0AB; Wed, 25 Feb 2015 11:30:44 -0800 (PST)
Received: from CAS-04.WIN.NOMINUM.COM (64.89.235.67) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 25 Feb 2015 11:30:44 -0800
Received: from [10.0.20.107] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 25 Feb 2015 11:30:43 -0800
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <CAJE_bqcq-Q2+FiewZxp9VbP5+5c2ynFZrX3zhcfrPt+V8DDdDw@mail.gmail.com>
Date: Wed, 25 Feb 2015 14:30:36 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <DC180CDE-E2B8-4D2F-8B92-A65BCCD43CBD@nominum.com>
References: <201502211924.t1LJOZd9062437@givry.fdupont.fr> <91CF04C8-616A-4223-BB1F-B41941E176D0@nominum.com> <CAJE_bqcq-Q2+FiewZxp9VbP5+5c2ynFZrX3zhcfrPt+V8DDdDw@mail.gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/Y0SQQO52bIXR1PFvJKZfzXcVPo0>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Francis Dupont <Francis.Dupont@fdupont.fr>
Subject: Re: [dhcwg] on use case discussion for draft-ietf-dhc-sedhcpv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Feb 2015 19:30:46 -0000

On Feb 25, 2015, at 2:09 PM, 神明達哉 <jinmei@wide.ad.jp> wrote:
> In that sense I'd still love to see an answer to my specific question:
> http://www.ietf.org/mail-archive/web/dhcwg/current/msg16268.html
> (aside from whether to include that answer in the final document).

Here's the question:

> It's still vague to me...specifically what kind of attack should we
> worry about in the case of client->server authentication when we use
> the shared secret mechanism, and in which sense is it more serious
> than with the public/private key mechanism?

What we are trying to do with the public key is to identify a client and authenticate the client's identity.   If you want to phrase it in terms of preventing an attack, the attack it prevents is one client presenting another client's identity and getting access to the second client's resources because the credential it presents is never authenticated.

But in practice, as a general rule we simply don't ever bother to treat clients as having meaningful identities, because there is no way to authenticate them.   So we aren't trying to prevent an attack, really.   We are trying to provide an enabling technology that allows the network infrastructure to do something new, that it couldn't previously do.