Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18

Ted Lemon <ted.lemon@nominum.com> Thu, 08 May 2014 18: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 4B54A1A00BA for <dhcwg@ietfa.amsl.com>; Thu, 8 May 2014 11:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level:
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 jjRivlVfD1C5 for <dhcwg@ietfa.amsl.com>; Thu, 8 May 2014 11:30:11 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id E4EAD1A00B2 for <dhcwg@ietf.org>; Thu, 8 May 2014 11:30:10 -0700 (PDT)
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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A546D1B8219 for <dhcwg@ietf.org>; Thu, 8 May 2014 11:30:06 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 78E45190043; Thu, 8 May 2014 11:30:06 -0700 (PDT)
Received: from [172.19.131.142] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 8 May 2014 11:30:06 -0700
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <CAJE_bqc+Z8awb5773OLs8QtXuCRxYCWFRAKuQ9YP8anFwEQqsQ@mail.gmail.com>
Date: Thu, 08 May 2014 13:30:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <5D53E8BB-F692-4752-A1B2-9BB09747C58B@nominum.com>
References: <535FEDAD.5010103@gmail.com> <CAJE_bqen37j5UCsKZj6syVyvk2Xed4V_xGp-t4xY8shjmS+H5g@mail.gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AE43272@nkgeml512-mbx.china.huawei.com> <CAJE_bqe75D7oRJq=XmjPR9Dfvu3-AcL8kF9Pkm3JEOVsyxhr5A@mail.gmail.com> <5D36713D8A4E7348A7E10DF7437A4B923AE442FD@nkgeml512-mbx.china.huawei.com> <CAJE_bqc+Z8awb5773OLs8QtXuCRxYCWFRAKuQ9YP8anFwEQqsQ@mail.gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
X-Mailer: Apple Mail (2.1874)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/4qcJhhaXfkFIfpaTwKjjNX0H92A
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
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: Thu, 08 May 2014 18:30:12 -0000

On May 8, 2014, at 11:24 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:
>>> - whether we really need (public key) authentication in that
>>> direction, and if we do, why

Public key authentication makes sense in both directions.   Servers may be configured to grant different access to clients that authenticate than to clients that don't.  Clients may have lists of servers that either are known to be legitimate, or that are known to have worked in the past (leap of faith).   Being able to discriminate between a good server and a rogue server using this mechanism is desirable.

>>> - also if we do, what's the commonly expected model of "trust anchor":
>>> leap of faith or use of CA or something else, and if it's more
>>> likely to be a weaker model like leap of faith (I suspect so, for
>>> the direction of clients to servers), whether the motivation (1st
>>> bullet) is worth the weaker security

This seems to be out of scope for the current document, which just specifies a mechanism for authenticating transactions given that a key is known.   It's possible that this needs to be stated more clearly.   The reason (IMHO) why it's out of scope is that there are a variety of mechanisms that might make sense and that could be implemented.   For instance, a DHCP server might give an unknown client an address in a walled garden where it could arrange to pay for service, and then its key would be known to the DHCP server and could be used to authenticate service in the future without requiring registration.

>>> - and, if it's more likely to rely on leap of faith, what kind of
>>> consideration is needed

You mean in terms of risk assessments?