[dhcwg] proposed text of sedhcpv6 applicability

神明達哉 <jinmei@wide.ad.jp> Thu, 25 February 2016 19:46 UTC

MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Date: Thu, 25 Feb 2016 11:45:58 -0800
Message-ID: <CAJE_bqfAAnYquTkLKv72=8GuD1eDWyQGBdp+xAS5NWBsNXGgnQ@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/Q6TQ48wpYkRoKRXYH7SRz8c_tP4>
Subject: [dhcwg] proposed text of sedhcpv6 applicability
Precedence: list

This is my proposed text for the "applicability" discussion of
draft-ietf-dhc-sedhcpv6-10 (Section 5.5) I promised before.  It is
intended to replace the entire text with the proposed text.

--
JINMEI, Tatuya

5.5.  Applicability

   In principle Secure DHCPv6 is applicable in any environment where
   physical security on the link is not assured and attacks on DHCPv6
   are a concern.  In practice, however, it will rely on some
   operational assumptions mainly regarding public key distribution
   and management, until more lessons are learned and more experiences
   are achieved.

   One feasible environment in an early deployment stage would be
   enterprise networks.  In such networks the security policy tends to
   be strict and it will be easier to manage client hosts.  One
   trivial deployment scenario is therefore to manually pre-configure
   client hosts with the server public key and manually register
   clients' public keys for the server.  It may also be possible to
   deploy an internal PKI to make this less reliant on manual
   operations, although it is currently subject to future study
   specifically how to integrate such a PKI into the DHCPv6 service
   for the network.

   Note that this deployment scenario based on manual operation is not
   different very much from the existing, shared-secret based
   authentication mechanisms defined in [RFC3315] in terms of
   operational costs.  However, Secure DHCPv6 is still securer than
   the shared-secret mechanism in that even if clients' keys stored
   for the server are stolen that does not mean an immediate threat as
   these are public keys.  In addition, if some kind of PKI is used
   with Secure DHCPv6, even if the initial installation of the
   certificates is done manually, it will help reduce operational
   costs of revocation in case a private key (especially that of the
   server) is compromised.

   It is believed that Secure DHCPv6 could be more widely applicable
   with integration of generic PKI so that it will be more easily
   deployed.  But such a deployment requires more general issues with
   PKI deployment be addressed, and it is currently unknown whether we
   can find practical deployment scenarios.  It is subject to future
   study and experiments, and out of scope of this document.

[dhcwg] proposed text of sedhcpv6 applicability 神明達哉