Re: [dhcwg] Open Issues for Secure DHCPv6

"Bernie Volz (volz)" <volz@cisco.com> Sun, 08 May 2016 11:35 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CF912B00D for <dhcwg@ietfa.amsl.com>; Sun, 8 May 2016 04:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level:
X-Spam-Status: No, score=-15.516 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.996, 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 Ym-fdYdQUEW3 for <dhcwg@ietfa.amsl.com>; Sun, 8 May 2016 04:34:59 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B614E12D0E7 for <dhcwg@ietf.org>; Sun, 8 May 2016 04:34:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26865; q=dns/txt; s=iport; t=1462707299; x=1463916899; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pbs081BjhfCRnIgU6wOjrtZOWJwUKKCbzvFQRPZs2us=; b=UTNNp4pIGTZyvscYLFLnGFPbaIIi+AaO5r1MO2ik9W1DjuafgjXwzMGW 85Qkr9J18LVOZoyFBzv19DE7kuoM7EEQxDED2/DhVfs6KRj09Cvngt0Sp 5PLO4FIK++2QgWksXRtAUepPO5KTm+fqvX+S6my3R78eKVggm7eknCJuP M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CdBQAtIy9X/5NdJa1egmxMgVKtKItwgXaGEAKBGzkTAQEBAQEBAWUnhEEBAQEEeRACAQgRBAEBIQcHIREUCQgCBA4FiBUDE7klDYQ9AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYgWgVOBA4JDgWYCSoJ1gi4Fl3ExAYwigXmBaYRPgyqFNYdYh2IBIgI+ggUbgUtuhnwBHgeBFwEBAQ
X-IronPort-AV: E=Sophos;i="5.24,595,1454976000"; d="scan'208,217";a="270267293"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2016 11:34:57 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u48BYvfp021009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 8 May 2016 11:34:57 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.1104.5; Sun, 8 May 2016 06:34:56 -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.1104.009; Sun, 8 May 2016 06:34:56 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Lishan Li <lilishan48@gmail.com>
Thread-Topic: [dhcwg] Open Issues for Secure DHCPv6
Thread-Index: AQHRn7VOYWVi5D/aP0CPgYl2nwWpKp+fZrEggA6RT4D//7BdoIABkUKA///CQSE=
Date: Sun, 08 May 2016 11:34:56 +0000
Message-ID: <DEE5C2ED-825A-46BE-9D76-196BF1CCA7A9@cisco.com>
References: <CAJ3w4NcCu0J3_+8x0FuzoUK2=HxVaCddW3s5e9oL535BH0NKTA@mail.gmail.com> <25322a5ec897409093e904a7dc4549d3@XCH-ALN-003.cisco.com> <CAJ3w4NenOEwz0wqXSGQW_TtBJQB8_VnX_QyasBRUYo0Ler37HA@mail.gmail.com> <6fd73d6525e343f1a38d0e7f77554a03@XCH-ALN-003.cisco.com>, <CAJ3w4NfiW_g0hf06gbnrS+n940dNpEzuOywKOuaLQ0K29xthLQ@mail.gmail.com>
In-Reply-To: <CAJ3w4NfiW_g0hf06gbnrS+n940dNpEzuOywKOuaLQ0K29xthLQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_DEE5C2ED825A46BE9D76196BF1CCA7A9ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/8fZcd8FhQznh0TAMrr4-mFxtT8s>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] Open Issues for Secure DHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 08 May 2016 11:35:02 -0000

Lishan:

If that's the case (haven't yet read lastest sedhcpv6 draft) ...

So if you restrict these messages to have only these options (and at most a single instance - or receiver only looks at first instance) there is no attack vector? If another option appears, drop the message?

- Bernie (from iPad)

On May 8, 2016, at 6:16 AM, Lishan Li <lilishan48@gmail.com<mailto:lilishan48@gmail.com>> wrote:

Dear Bernie,

The options that may be contained in the Encrypted-Query and Encrypted-Response messages are only two options: server identifier option and encrypted-message option. The server identifier option is not must contained in the Encrypted-Query message until the server is selected. Only the encrypted-message option must be contained. In addition, the encrypted-message option does not have the fixed length.
So, it is better to contain a series of options, not flexed fields. Looking forward to your further guidance.

Best Regards,
Lishan

2016-05-07 23:25 GMT+08:00 Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>>:
Hi:

Regarding 6. The format of Encrypted-Query and Encrypted-Response messages.

Please provide details on how this message would be formatted.

Given that with 4-byte option headers (assuming 0 length), a fairly large packet (such as 65K) could have about 16K options in it so would take that many iterations to process and discard. For more reasonable length packets, this probably is much less of an issue (100s of iterations).

While we generally avoid option ordering, perhaps an alternative to a fixed header (especially if some of the fields aren’t fixed length) is to specify that those options “required” for validation are “first”. That would make it very easy for a server (or client) to quickly discard a packet when it cannot be properly “validated”. This might provide the benefit you’re looking for but avoid the need for the fixed length header (especially if it isn’t “fixed” length).


-          Bernie


From: Lishan Li [mailto:lilishan48@gmail.com<mailto:lilishan48@gmail.com>]
Sent: Saturday, May 07, 2016 11:05 AM
To: Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>>
Cc: dhcwg <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>
Subject: Re: [dhcwg] Open Issues for Secure DHCPv6

Dear Bernie,

Thanks a lot for your nice reply. Please see in line.

Best Regards,
Lishan

2016-04-28 21:48 GMT+08:00 Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>>:
Hi:

A few comments below (BV>). For those questions I did not have a comment on, it means I’m not yet sure what to say.


-          Bernie

From: dhcwg [mailto:dhcwg-bounces@ietf.org<mailto:dhcwg-bounces@ietf.org>] On Behalf Of Lishan Li
Sent: Tuesday, April 26, 2016 8:15 AM
To: dhcwg <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>
Subject: [dhcwg] Open Issues for Secure DHCPv6

Dear All,

After the discussion with Ted and Jinmei, there are still some open issues. Regarding these open issues, could you please give us you suggestions? Looking forward to your guidance! The following are the current open issues:

1. A single DHCPv6 server selection for authentication at the beginning.
If the two servers share one common certificate with the same public key, then the client should be able to send an encrypted request to both servers, and both the servers can decrypt the encrypted request and letting client select one of them in a compatible way to the original DHCPv6.
So in this way, there is no need to contain the Server Identifier option in the Encrypted-Query message. The disadvantage is that the extra decryption cost is caused for the DHCPv6 server not for it.

BV> How about adding the server-identifier option when it is in the client message (i.e. Request, Renew, Decline, Release). That way, once a server is selected the other servers can ignore without needing to decrypt? That reduces the load a bit.
[LS]: Thanks for your valuable suggestion.  In this way, only after server selection process, the server identifier option is contained to avoid the extra decryption for the servers not for it.

2. Regarding timestamp, what about a strictly-increasing serial number (with rollover)?
The advantage of a strictly increasing number is that the server can just discard messages from the client with lower numbers, and the client can do the same.  The disadvantage is that the strictly-increasing number has to be committed to stable storage on the client.

BV> This seems a bit tricky. What happens if the stable storage is lost? A time based value (when possible – i.e., client has time) seems like a better option to me? For clients that don’t have the current time (i.e., need DHCP to get the time), perhaps the timestamp is optional to accommodate them – this does mean there is the replay risk (at least until a time is available). I prefer we use existing techniques for this and I think they are generally time based?
[LS]: Generally, the timestamp is used to defend against replay attack. I also prefer the existing techniques for this.

3. For the DHCPv6 client, how about a bare key not a certificate?
If the client uses certificate for authentication. The client has to generate a key and then submit it to a certificate authority to be signed. It would make sense for two different companies to trust all certs signed by the same authority. For the client which is no longer authorized, they still have a key signed by the authority.   How do we stop that one client from authenticating? The answer is that we have to have a record of every client that is authorized to use the network.

There are two ways to do client authentication: first, we can have the certificate authority remember all of the clients, and maintain a certificate revocation list (CRL) for clients whose certificates should no longer grant access to the network. Second, we can simply keep a list of all the client keys that are granted access to the network, and the DHCP server can check that list before granting access.

The first one is more easy, so we think a bare key is enough not a certificate.

4. Whether we should mention opportunistic security in secure DHCPv6?

5. For the clients which has multiple certs, whether the transaction-id can work as the identifier of the client's public key for encryption, and server's  private key for decryption?

BV> I’m not sure I understand this one.

6. The format of Encrypted-Query and Encrypted-Response messages.
For the encrypted-query and encrypted-response messages, in the current version, the payload is a series of options, which may cause unnecessary attack. So according to Ted's suggestion, It is better that the payload is encrypted message with some fixed field. But DHCPv6 message's format are a series of options. If the encrypted-query and encrypted-response use the above format, are they still DHCPv6 messages?

BV> I really prefer we keep it as a series of options. I don’t see that fixed fields help anything (especially if fields are variable length, why are they any easier to parse than options?). Options are easy enough to parse.

I don’t see this as “are these DHCPv6 messages” or not argument – the Relay-Forw/Relay-Reply messages use a combination of fixed fields and options and we consider these as DHCPv6 messages.

Perhaps if you can provide an example of how these messages would be formatted with the fixed fields, we could better evaluate as to whether this may make sense or not. (For example, perhaps you want to add some “identifier” into the messages to address issue #5 above?)
[LS]: If the encrypted message contains a series of options, then a client may send additional options and a server may also do it. So this way may create an unnecessary attack surface.
Compared with a series of options, I think fixed fields may be better.

Best Regards,
Lishan