Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17

Lishan Li <lilishan48@gmail.com> Tue, 29 November 2016 15:19 UTC

Return-Path: <lilishan48@gmail.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 9B103129BFA for <dhcwg@ietfa.amsl.com>; Tue, 29 Nov 2016 07:19:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KtamX8kNG3Jv for <dhcwg@ietfa.amsl.com>; Tue, 29 Nov 2016 07:19:57 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045241293FD for <dhcwg@ietf.org>; Tue, 29 Nov 2016 07:19:57 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id q130so177513594qke.1 for <dhcwg@ietf.org>; Tue, 29 Nov 2016 07:19:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/ilfE/XH4FYDOFE+i0es1JTNMKHzFzG7S7qoF5Py/KI=; b=XAqapr5cIx4nyXIVsPtX20wmjWovfk86tXc5soyuOK2UfR3/qlq8b5uDU2QD21HoCB buRG5ULKV9jEvJKSE0LjCsXtiA8U9l6qQ3wDID4VDI1wy9KMTKVadFX3KXnQxJqL2Sw7 WkMBOb0xuuX1SoWoW2gAt9UPi3DYgNyBZhbpgt+vKgAk1JMuRz5SU2M5ZRITdDIBqaz8 cXCU8S9W5XWqeioI9TFYsn43falhdO38wVGyGV99gouEybnDt9IooEIbvNxH/1ZKTRoG k5daXSPN1Lev+t8zf5wKqKvuwZOpQbAboG2us30ccqr2//j/ojTbtMDn9rrJhqy3cw36 hiyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/ilfE/XH4FYDOFE+i0es1JTNMKHzFzG7S7qoF5Py/KI=; b=PFk2S8ejoq9bPA0GT2mlohxeYwuRmLqUzFxg2ar7YaSt/lG0j+Op/ibB7FO9yzAmJO BrhQ9Utx7Vuw0vewFpWyGo7G3aNTvSrC4tqPhv4DhTVpaRD5VcCE7rW+BGhh+ebffuyr Xg9KbVhh5ifu7NH/n4verrIPf81zrSLJclwRP+JF4a4tQyIMTA2Zb7pF4jLiCW5KT2HQ HZ1fHrwp10dO2S6DbaQTuYjD9NQa5aHBM+EsY6ArnTGLCJe2wCLCQjD9tl6AuPOKb26Y kKRnPgHe+U+jreWBWROKUSo4PioodW/evkc8PeADYPVEs1clUpaC74US9HBylKfm87Jq w/cA==
X-Gm-Message-State: AKaTC01Di3KOhWexSxj3mY1XBT2H+96WskD3se/ZcHMY1+ZonVgApnang9CfErcH4J/14e9W3AcbwMSwUD5KGg==
X-Received: by 10.55.17.68 with SMTP id b65mr23985907qkh.60.1480432796003; Tue, 29 Nov 2016 07:19:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.36.211 with HTTP; Tue, 29 Nov 2016 07:19:55 -0800 (PST)
In-Reply-To: <CAJE_bqceRD2+vkfwR+Egr=CgyAT4wd1Wmxp1S=f3WRFGs9j4sg@mail.gmail.com>
References: <CAJE_bqebwr2WUUgaNgiYS4_8L77Gxj4Os+oPRG407B6ELMEhCQ@mail.gmail.com> <CAJ3w4Ndi5Gq63n5kZnanRhLM8nWE2wsWGh0kJJLJnq=VoXLuCg@mail.gmail.com> <CAJE_bqegh1DfWjfK2BxeC_fWa0cEk-KJNP0AT-TQuEa39w_wVQ@mail.gmail.com> <CAJ3w4NdM99nv4C19Xj=aosNme+_Ymyys=xQ3UWUfeZReZC4ckA@mail.gmail.com> <CAJE_bqdhGZnK16MooiyujDgthDNnR74EiwW0OevrN6uq4b4ANw@mail.gmail.com> <CAJE_bqfKUZe2yaW1sAq7rrib0M7wz28HHtPLqCHK=vXcN6amgg@mail.gmail.com> <CAJ3w4Nd3s+ZojjiotLkKwys6truhUgK6F-90UYjcpB9iw=fKKQ@mail.gmail.com> <m2r36nuqvn.wl%jinmei.tatuya@gmail.com> <CAJ3w4NeuNYTrX4p5rtZ6UceD5ydQ-B-vY6aqQzxWnXsrDOEFEA@mail.gmail.com> <CAJE_bqdh-bgk7BHZJnaFFBr3PDj4ZnSSGeGNdQ70F7dv91iQrA@mail.gmail.com> <CAJ3w4NfU9PrC9a+MGnJ=Es1yir_asHB3p1=9GfxZZ0iSe+At+Q@mail.gmail.com> <CAJE_bqfRBYkrniWQ+vtPULTURnvyV792QNGvr8JhhZpGQ0MSdA@mail.gmail.com> <CAJ3w4NerRzHYsRqcUAkAjHX23PYVF4Jv0wKcd33vXRRg+-0EAQ@mail.gmail.com> <CAJ3w4NekPk0TuAZW_jmTDYQHd8JP3GsrA0qrKYrnyqSSk3qwxw@mail.gmail.com> <CAJE_bqc8hkrc3dYefTPWi-mUCtZD+oYsrobCK1KjmVGRnNfMCw@mail.gmail.com> <CAJ3w4NejrFAT3RK7i0W46HkQNJjhPxbhzQiL=3fcrceidTzHNQ@mail.gmail.com> <CAJE_bqcCwZWPHuZ0UR8_jyCUsaTrYKzLD8zUKwChYaCL06yT9A@mail.gmail.com> <CAJ3w4NfS8PKOMHcP5s_Nsp5K5eWJfXWRF-vNEau_ekqTRwE=wA@mail.gmail.com> <CAJE_bqfqSXFR9R5wf1USg-zs+nvdohQFq99kQL2DiapXvUdEqA@mail.gmail.com> <CAJ3w4Ncj40JwrW6UB+TVFvymByU5Y9iFv5QroWhwUzkLrS2DTg@mail.gmail.com> <CAJE_bqd38grUh9q57a-H29GsMx5Dpv9VE0iBMO7v_-y97zZZUg@mail.gmail.com> <CAJ3w4Ne63cnqoeTZk=PDmAN9+i6jwzyxbK+up45wB9h+xUDSfw@mail.gmail.com> <CAJE_bqceK7YLpMqhgjqrFQh7641a+ZRcnO0F6p6BiM8EMKmA7w@mail.gmail.com> <CAJ3w4Nf65b1zo-smMguZBc_-RbFh2y8kk7Fnu__TKCQEVbs48w@mail.gmail.com> <CAJE_bqeVciLxS_q=deRKLBr12ZGXxx2wdFiztJxJjfS7aAV2Ag@mail.gmail.com> <CAJ3w4NcvyeuRWJatGGH7U4g413GQvr9LHtDiX13zSOz7kBGEhw@mail.gmail.com> <CAJE_bqfFOhe26huAP8_BFKjnTXbG4F0vUfMYs5Xy=3RQigS7FA@mail.gmail.com> <CAJ3w4Ne81LVsaznu_yck7fG7iJyGm=WY4=i2AF8gx39Tf59eMA@mail.gmail.com> <CAJE_bqceRD2+vkfwR+Egr=CgyAT4wd1Wmxp1S=f3WRFGs9j4sg@mail.gmail.com>
From: Lishan Li <lilishan48@gmail.com>
Date: Tue, 29 Nov 2016 23:19:55 +0800
Message-ID: <CAJ3w4NcnAe3Enhs6KVgBkpa+BivLGRw9SGJ1RmAq7q=HM8Ph6Q@mail.gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary="001a1146f106eb74ac0542721e48"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/C9fFQsilXu44bRE-jBcPYOcdrAc>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17
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: Tue, 29 Nov 2016 15:19:59 -0000

2016-11-29 2:00 GMT+08:00 神明達哉 <jinmei@wide.ad.jp>:

> At Fri, 25 Nov 2016 14:29:41 +0800,
> Lishan Li <lilishan48@gmail.com> wrote:
>
> > > Anything that would generate reasonably different values for different
> > > keys (but it doesn't have to be guaranteed) is fine.  A simple
> > > "checksum" like the RRSIG key tag would probably suffice; using a
> > > commonly known modern hash is also fine.
> > >
> > [LS]: So it is mostly a implementation problem and don't need to specify
> > it.
>
> We need to describe it as part of the protocol as it's necessary for
> interoperability.  It's similar to the fact that the calculation of
> the DNS RRSIG key tag is part of the protocol standard.
>
[LS]: OK. So how about using the hash algorithm for the encryption
key tag calculation?
Maybe the server don't need to know the calculation method. For the
first Encrypted-Query message with the new encryption key tag, the
server tries all the possible private keys and record the relationship
between the key tag and the corresponding public/private key pair.
And the server does not need to calculate the key tag locally.

>
> > Another problem is that: how the client identify which public/private key
> > pair is used for DHCPv6 configuration process when the client have
> multiple
> > key pairs. In most cases, the client communicate with only one DHCPv6
> > server. Then, the client only uses one public/private key pair for the
> > DHCPv6 configuration process. So there is no need to define the
> mechanism.
> > Could you please check whether my understanding correct?
>
> In this case we can normally use the transaction ID (unlike the case
> where the server needs to identify the key pair to decrypt the
> received data)...except for Reconfigure.  So, in the end we probably
> need to include the key tag option in the Encryption-Response
> message.  Hmm, this leads to another question: which encryption
> message should we use, Encryption-Query or Encryption-Response, to
> encrypt a Reconfigure message?
>

[LS]: The Reconfigure message is sent from server to client. So sure,
it should be encrypted in Encrypted-Response message.

Firstly, I think there is no need to design such a mechanism for it.
The DHCPv6 server communicates with multiple DHCPv6 clients.
So there is need to define a mechanism to identify the used public/private
key pairs. However, the client always communicates with only one DHCPv6
server. For the whole DHCPv6 configuration process, only one public
key is informed of the server and the corresponding public key is used
for decryption.

Assume it is need to design a mechanism for this. There are three method:
1. Transaction id as the identifier: now work for Reconfigure message;
2. Encrypted-Response message contains key tag.
3. Server Identifier as the identifier.