[dhcwg] Secure DHCPv6 Deployment Consideration - proposed text

Sheng Jiang <jiangsheng@huawei.com> Tue, 25 August 2015 02:56 UTC

Return-Path: <jiangsheng@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CE2DD1AD364 for <dhcwg@ietfa.amsl.com>; Mon, 24 Aug 2015 19:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VnN0nASCcb5p for <dhcwg@ietfa.amsl.com>; Mon, 24 Aug 2015 19:56:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB74B1AD359 for <dhcwg@ietf.org>; Mon, 24 Aug 2015 19:56:48 -0700 (PDT)
Received: from (EHLO lhreml406-hub.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWS29295; Tue, 25 Aug 2015 02:56:46 +0000 (GMT)
Received: from NKGEML404-HUB.china.huawei.com ( by lhreml406-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Tue, 25 Aug 2015 03:56:46 +0100
Received: from NKGEML512-MBX.china.huawei.com ([]) by nkgeml404-hub.china.huawei.com ([]) with mapi id 14.03.0235.001; Tue, 25 Aug 2015 10:56:41 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: Secure DHCPv6 Deployment Consideration - proposed text
Thread-Index: AdDe4avSo3+rdoOWTrG1Qtr8UgPnSg==
Date: Tue, 25 Aug 2015 02:56:40 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BB250CE@nkgeml512-mbx.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/KDOJy_lbKI-p_17BTwyNOzfW-dg>
Cc: "draft-ietf-dhc-sedhcpv6@tools.ietf.org" <draft-ietf-dhc-sedhcpv6@tools.ietf.org>, "dhc-chairs@tools.ietf.org" <dhc-chairs@tools.ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: [dhcwg] Secure DHCPv6 Deployment Consideration - proposed text
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 25 Aug 2015 02:56:52 -0000

Hi, dhc,

During the latest AD review and security review, we have received many constructive comments. Although some general security issues are out of scope, we have integrated most of comments. One of the major concern is regarding to the deployment/applicability, particularly the PKI availability. Therefore, we have proposed the below text for a new section, deployment consideration. Your review and comments are appreciated.

Deployment Consideration

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.

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.

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.

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.

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.

The server may constrain the resource and access rights to clients who is 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.

Best regards,

Sheng + Dacheng