Re: [Dhcpv6bis] [dhcwg] seDHCPv6 update and next steps ...

"Bernie Volz (volz)" <volz@cisco.com> Mon, 24 July 2017 21:32 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcpv6bis@ietfa.amsl.com
Delivered-To: dhcpv6bis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFFA131F2F for <dhcpv6bis@ietfa.amsl.com>; Mon, 24 Jul 2017 14:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 wzUruQejkkgl for <dhcpv6bis@ietfa.amsl.com>; Mon, 24 Jul 2017 14:32:41 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860B8131F2E for <dhcpv6bis@ietf.org>; Mon, 24 Jul 2017 14:32:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25495; q=dns/txt; s=iport; t=1500931961; x=1502141561; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2b9856h0zTu6tyfFSVwJdryoVv9bov4BDfN4ZaWKbW0=; b=EwBxnz3RwoqL6EcgBmclSbJsWQnp/g9tFsyNVryeFGOO5IZ5eRtxCt8S GAOdejNSPVrhiL8FgeiOm7B3FSPvtj/mwDL2INfLag9IPIIRRVDga/UAZ K5uNvUhI6mVCdmhBJfEURab4e7EwdOSvHMbD0kl+WBYnTSidueiyShoIH A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DAAABnZnZZ/4MNJK1TCRkBAQEBAQEBAQEBAQcBAQEBAYJvPi1kgRQHjgWRaHSHO4gqhSyCEi6FGQIag1E/GAECAQEBAQEBAWsohRgBAQEBAyMKTBACAQYCEAEEAQEoAwICAh8RFAkIAgQBDQUIBhGJeAMVEJFHnWSCJoc0DYQGAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgoFgyiFLoJwNIJXT4EeEQJKgl2CYQWRJ4Ymh0U8AoQugx6HYIRnghWQK4lKgkaJUwEfOEw+dRWFXByBZ3aHJIExgQ4BAQE
X-IronPort-AV: E=Sophos;i="5.40,408,1496102400"; d="scan'208,217";a="263617222"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jul 2017 21:32:40 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6OLWeGl022314 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Jul 2017 21:32:40 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Jul 2017 16:32:39 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Mon, 24 Jul 2017 16:32:39 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ted Lemon <ted.lemon@nominum.com>, "'dhcpv6bis@ietf.org'" <dhcpv6bis@ietf.org>
CC: "draft-ietf-dhc-sedhcpv6@tools.ietf.org" <draft-ietf-dhc-sedhcpv6@tools.ietf.org>, 神明達哉 <jinmei@wide.ad.jp>, Lishan Li <lilishan48@gmail.com>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Thread-Topic: [dhcwg] seDHCPv6 update and next steps ...
Thread-Index: AdL7TPjzgLDuRsMjTzK32MYQ2IpqqADS4bJcAA5GH1MAC6MmgP//rbUSgAN1qgD//77xgIAI2UeAgAA44KA=
Date: Mon, 24 Jul 2017 21:32:39 +0000
Message-ID: <87f4ce9751c749d5813173ccb7e23598@XCH-ALN-003.cisco.com>
References: <925C7354-4E62-4908-8CB7-87B3291B9DEF@cisco.com> <54257e9e-3241-46fd-a4ca-29598aea869e@email.android.com> <CF263D55-1F72-4325-B43D-CE4046965B7A@cisco.com> <0E680EBF-75EE-495F-B43A-5D212FF8DA91@nominum.com>
In-Reply-To: <0E680EBF-75EE-495F-B43A-5D212FF8DA91@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.1.198]
Content-Type: multipart/mixed; boundary="_004_87f4ce9751c749d5813173ccb7e23598XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcpv6bis/RQSwveuu7F3Hn5dOXXGDvPlxYa4>
Subject: Re: [Dhcpv6bis] [dhcwg] seDHCPv6 update and next steps ...
X-BeenThere: dhcpv6bis@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "DHCPv6 \(RFC3315\) bis discussion list" <dhcpv6bis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcpv6bis>, <mailto:dhcpv6bis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcpv6bis/>
List-Post: <mailto:dhcpv6bis@ietf.org>
List-Help: <mailto:dhcpv6bis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcpv6bis>, <mailto:dhcpv6bis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2017 21:32:45 -0000

Hi Ted:

Ok, thanks for that update. You might not need to follow up further … I think it may just depend on what happens with 3315bis when we get it to the IESG.

I think the main issue will be to figure out what text to add/change in the 3315bis document for the -10 (i.e., the version we plan to publish shortly and hopefully send on).

I was planning on taking a first stab at that but if anyone else has cycles (I likely won’t this week) …

I did copy the existing section 22 and 23 into https://docs.google.com/document/d/1sIH0vbaM26zEuOlneTFSB_0TOK56pZKVLlA1R-KelLQ/edit?usp=sharing (removed RFC formatting so it is just text, but still does include hyperlinks). In first paragraph, I did remove the 2nd sentence since we don’t want to mention sedhcpv6 but made no other changes yet.

The analysis that Francis did might help (attached), but he didn’t address whether the server’s response contained anything that could be “sensitive” (probably not). And snooping of that might be more difficult in many situations (since it is unicast, and often switches only send those packets to a single port).

I also wonder if we should have sub-sections to discuss general issues and different types of networks (enterprise vs coffee shop)? Or somehow break up the section a bit? We also don’t mention the SAVI work and perhaps one or more of those RFCs could also be useful to reference?


-          Bernie

From: Ted Lemon [mailto:ted.lemon@nominum.com]
Sent: Monday, July 24, 2017 3:36 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: draft-ietf-dhc-sedhcpv6@tools.ietf.org; 神明達哉 <jinmei@wide.ad.jp>; Lishan Li <lilishan48@gmail.com>; Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Subject: Re: [dhcwg] seDHCPv6 update and next steps ...

On Jul 19, 2017, at 4:27 AM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote:
We can certainly follow up with her on that, but I think it is the pervasive monitoring …

I did follow up with her.   As far as I was able to gather from talking to her, she does not have a clear use case either, and she hadn't realized that 802.1x+relay security gets us security in the enterprise environment, so she was quite mollified by that.

I'm going to have a chat with her next time I'm in Boston and see if we can get some clarity on this.


--- Begin Message ---
Here I put a (not so) short analysis of opportunistic encryption with
(or versus) DHCPv6.

First the use case is the so called "coffee shop" one. There is a network
(likely WiFi) providing an Internet access to persons (customers) in
the radio range.
 The goal is to provide privacy, i.e., the use of the DHCPv6 protocol
to get a global IPv6 address assigned do not reveal something interesting
to a passive attacker (eavesdropper).

Implications of the use of DHCPv6 on privacy were well studied in RFC
7824 and an anonymity profile defined in RFC 7844. Typically the client
should not try to update the DNS (BTW there is no reason to update
the DNS in this use case so this is just to complete the analysis) and
the identity information is available only in the DUID which can be based on:
 - the MAC address (note as this option is required for stable DUID
  without stable storage most client implementations support this option,
  i.e. there is nothing special to do for the user)
 - an UUID so 128 random bits
The client DUID is opaque for the server: the only constraint is the
same DUID must not be used by 2 clients at the same time. This is
fulfilled by the MAC address (if 2 clients use the same MAC address on
the same link the problem is greater than DHCPv6) and the DUID (anyway
there are only 2^64 addresses available per link :-).

So IMHO even without specific care the DHCPv6 protocol in this use case
does not need to be protected against eavesdroppers so dedicated
oportunistic encryption is useless.

Now look at around.

DHCPv4 is like DHCPv6 but from its long history it didn't got a very
good design. For instance it embeds the MAC address making hidding it
inside the protocol itself harder (i.e. it can require specific setup).
 Anyway the 2 RFC about privacy and anonymity apply to both DHCPv4 and
DHCPv6 so there is no unknown or untrackable problem here.

To assign IPv6 addresses one can use the SLAAC mechanism, i.e., the
Neighbor Discovery (note there is a secure version of it named SeND
in RFC 3971 but it is only about authentication and a bit of
authorization). The choice between SLAAC or DHCPv6 for address
assignment and for other common paramaeters (e.g. DNS server addresses)
is at the choice of the network manager.

On the opportunistic side DHCPv6 uses multicast to discover the agent
(relay or server) on the link and may get an address in one (rapid
commit) or two exchanges (one exchange : a query from client to agent,
and a response from agent to client. The query is sent from a link-local
address to a multicast one).
 This is not supported by any standard key-exchange protocol so IMHO
by opportunistic encryption something like IPsec is referred to.

So if IPsec is used to provide the opportunistic encryption this means
the client picks a self signed or raw key (anything else will be both
too complex with no benefit and vulnerable to active attacks as IKEv2
chose to protect the responder identity against active attacks) and
runs IKEv2 with an agent which was discovered using a to-be-defined
mean.
 It can work but IKEv2 offers by the Configuration Payload (RFC 7296
section 3.15) address assignment so I can clearly claim if there is
a possibility to get IPsec deployed in the coffee shop use case
then there is no reason to not get rid of DHCP at the same time.

Note if the use case is changed to include prefix delegation
the trade-offs are pretty different. A delegated router
(i.e. a prefix delegation client) has already an address with
a large enough scope to be able to communicate directly with
the DHCP server. So it can embed a relay and apply the DHCPv6
security mechanism between relays and servers which is BTW IPsec.
(I proposed the embedded relay idea for mobile delegated routers
in RFC 6276.)

In conclusion I claim there is no clear use case to justifying to
invest resources into a work about dedicated (to DHCPv6 privacy
protection) opportunistic encryption.

Regards

Francis.Dupont@fdupont.fr
--- End Message ---