Re: [dhcwg] Secure DHCPv6 Deployment Consideration - proposed text

"Dacheng Zhang" <> Thu, 27 August 2015 10:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B66A61A8A79 for <>; Thu, 27 Aug 2015 03:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.45
X-Spam-Status: No, score=0.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BtBIAs-D6Jma for <>; Thu, 27 Aug 2015 03:24:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DB5EF1ACD3E for <>; Thu, 27 Aug 2015 03:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1440671042; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=0vDumqy8ax5e4Ez2TAOI0PMAgtyw/Hgkdi6iaomC+qI=; b=IBOotOR3jKonOkhWsWFMgW/EruM6ejqcpuaqLrfGv96ejHeVq+vFUXnLoXOjN7Ug9wmDkh5AXcMPOO+EI+tjP4O1fuDwSNSpqsT5tBa6UglhaTfMBHQ33Sp+gWUrucAT4JindEprKTj34tvTMfcC2vCAgKUKs4+728qz4y9uqfY=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03271;; NM=1; PH=DS; RN=4; SR=0;
Received: from ip: by; Thu, 27 Aug 2015 18:23:56 +0800
User-Agent: Microsoft-MacOutlook/
Date: Thu, 27 Aug 2015 18:23:49 +0800
From: Dacheng Zhang <>
To: Sheng Jiang <>, 神明達哉 <>
Message-ID: <>
Thread-Topic: [dhcwg] Secure DHCPv6 Deployment Consideration - proposed text
References: <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="GB2312"
Content-transfer-encoding: quoted-printable
Archived-At: <>
Cc: "" <>, Ted Lemon <>
Subject: Re: [dhcwg] Secure DHCPv6 Deployment Consideration - proposed text
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Aug 2015 10:24:05 -0000

在 15-8-26 下午4:59, "dhcwg on behalf of Sheng Jiang"
on behalf of> 写入:

>Hi, Jin,
>My replies in lines.
>>> This document defines two authentication models: authentication
>>> based on public key certificates and PKI; and authentication based
>>> on leap of faith to public keys. It is worth noticing that in real
>>> deployment, the two models may be mixed together on the serve to be
>>> able to serve both stable clients and roaming clients, which may be
>>> treated with different service policies.
>>I thought we chose to use TOFU (Trust-on-first-use) instead of "leap
>>of faith".  Is it intentional this text now uses the latter?
>Yes, TOFU. I will check the consistency when integrating these text into
>the document.
>>> 1. Authentication based on certificate and PKI
>>> This model would mainly be used in the scenarios such as enterprise
>>> networks where tight security policies are applied and the clients
>>> are stable terminal devices. It would provide tighter security
>>> protection because both server and client can be authenticated based
>>> on a common trusted CA. As with this precondition, this model would
>>> require more complicated pre-configuration, particularly on the
>>> client side.
>>Once we say "require more complicated pre-configuration", we'll lose
>>the most boasted advantage of this proposal: ease of deployment.  So
>>text like this will also need to answer "then, why do we bother
>>to introduce a new mechanism?"  I thought this question is one of the
>>common feedback (or pushback) from post-WGLC reviews, and will have to
>>be addressed in some way.
>>In my understanding, the honest answer is that "we think public-key
>>based mechanism is just more modern, that's it".  We could also note a
>>relatively minor security advantage in cases like silently stolen
>>client keys on the server.  There might also be cases where we can
>>show this approach actually improves deployability, but from the
>>lessons I learned from previous discussions I suspect such discussions
>>will be speculative at best, and will be unlikely to satisfy the
>PKI-based deployment is easier than symmetric key mechanism, particularly
>when there are multiple servers. PKI is more modern and common. It may be
>combined with other protocol deployment, not only DHCPv6. I will try to
>enhance the text, but such discussion actually belong to section 3,
>"Security Overview of DHCPv6".

In addition, the capability of generating cert chains can provide
additional flexibility than the solution based on pre-shared keys.

>>> The server can always be considered to have connectivity to
>>> authorized CA and verify the clients’ certificate. Because the
>>> client may have to validate the authentication in the condition of
>>> without connectivity wider than link-local,the verification on the
>>> client devices may have to be performed locally. One or multiple
>>> certificates, which form a certification path [RFC5280], need to be
>>> deployed in the client in order to verify the certificate sent from
>>> the server and so perform the authentication. Besides the
>>> certificate used to prove the identity, the server may also need to
>>> provide additional certificates to help the client generate a
>>> certificate chain from the certificates deployed in the client to
>>> the certificate.
>>I'm not sure if this paragraph directly and clearly addresses the
>>concern regarding how the client validates the certificate or public
>>key.  I suspect we'll need to discuss something more specific, like
>>how a client could pre-cache a complete certification path with
>>discussions on its own risks.
>The establish, deployment and its risks of certification path is another
>generic issues, which a) is out of scope, it is secure dhcpv6 specific,
>b) it is addressed in the referred RFC.
>>> 2.  Authentication based on leap of faith
>>> This model would mainly be the scenarios that the security policies
>>> are loss and the clients may roam, such as public coffee
>>> shops. Therefore, the PKI could not be deployed in advance. This
>>> model requires minimum pre-configuration - server and client has a
>>> public/private key pair. A signed certificate could be an equivalent
>>> to a public key in this model.
>>Several reviewers have already pointed out that TOFU (or leap of
>>faith) is not suitable for coffee shop cases (and I agree with them).
>>My personal answer to them is that a more appropriate case would be
>>initial setup in a closed home network.  We might also say TOFU can be
>>used for hijack prevention.
>Let's see what the reviewers may response. I can certainly modify the
>example. But I am not sure what else is the best model for coffee shop.

Maybe we could assume the customer needs to input the wifi password on the
wall first.... 

>>> The Leap of faith model by itself could not prevent a client to
>>> trust a malicious server or a server to trust a malicious client at
>>> the beginning of the first session. But the leap of faith mechanism
>>> guarantees the subsequent messages are sent by the same previous
>>> sender, and therefore narrows the time window that an attacker can
>>> perform attacks. Also, the message integrity is provided.
>>what does "also, the message integrity is provided" mean in this
>It means the receiver can validate the message does not modified in the
>>> The server may constrain the resource and access rights to clients who
>>based on leap of faith model to avoid potential malicious attacks
>>> Additional mechanisms to justify the trust relationship, such as
>>> requiring human intervention at the point of the leap of faith on
>>> the client or the server may run some algorithm to detect malicious
>>> behaviors from clients.
>>"some algorithm to detect malicious behaviors from clients":
>>specifically what does this mean?
>>If I remember correctly, there was also a concern about privacy leak
>>by exchanging clients' public keys or certificates.  Do we have
>>another section to address this point?
>I believe this has been mentioned, although not solved, by the last
>paragraph of section 7, Security Considerations.
>>Finally, a couple of editorial nits:
>>> the two models may be mixed together on the serve to...
>>s/on the serve/on the server/?
>>> The Leap of faith model by itself could not prevent a client to
>>> trust a malicious server or a server to trust a malicious client...
>>s/to trust/from trusting/ (2 occurrences).
>Thanks. Corrected.
>>JINMEI, Tatuya
>dhcwg mailing list