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

Sheng Jiang <jiangsheng@huawei.com> Wed, 26 August 2015 08:59 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A59A1AC3DF for <dhcwg@ietfa.amsl.com>; Wed, 26 Aug 2015 01:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level:
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SScozF34LgWq for <dhcwg@ietfa.amsl.com>; Wed, 26 Aug 2015 01:59:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83EC1A916E for <dhcwg@ietf.org>; Wed, 26 Aug 2015 01:59:36 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWT78837; Wed, 26 Aug 2015 08:59:34 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 26 Aug 2015 09:59:33 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.33]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Wed, 26 Aug 2015 16:59:28 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Thread-Topic: [dhcwg] Secure DHCPv6 Deployment Consideration - proposed text
Thread-Index: AdDe4avSo3+rdoOWTrG1Qtr8UgPnSgAQRAyAACvrM7A=
Date: Wed, 26 Aug 2015 08:59:27 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BB26A26@nkgeml512-mbx.china.huawei.com>
References: <5D36713D8A4E7348A7E10DF7437A4B927BB250CE@nkgeml512-mbx.china.huawei.com> <CAJE_bqcWy98HJGTu9SNpQh8eoPVnhsHwQ7fSLfq44dkAL6u4DA@mail.gmail.com>
In-Reply-To: <CAJE_bqcWy98HJGTu9SNpQh8eoPVnhsHwQ7fSLfq44dkAL6u4DA@mail.gmail.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.197]
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/U7LlDqyeXaEzDPYYQeoTA1Ug0tQ>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [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: Wed, 26 Aug 2015 08:59:41 -0000

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
>reviewers.

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".

>> 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.

>> 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
>context?

It means the receiver can validate the message does not modified in the middle.

>> 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.
>
>"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.

Regards,

Sheng

>--
>JINMEI, Tatuya