Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
"Bernie Volz (volz)" <volz@cisco.com> Fri, 02 May 2014 12:33 UTC
Return-Path: <volz@cisco.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 9D1F01A6F74 for <dhcwg@ietfa.amsl.com>; Fri, 2 May 2014 05:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Level:
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 WY3_hkPe500I for <dhcwg@ietfa.amsl.com>; Fri, 2 May 2014 05:33:57 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id D3FA91A6F44 for <dhcwg@ietf.org>; Fri, 2 May 2014 05:33:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5403; q=dns/txt; s=iport; t=1399034034; x=1400243634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0fAT0wija25+ffPHj+gp8mTQBBdTnY3Andx47b6oTXQ=; b=a/Czptll4DmUwmVBFE3i8NCcUldyYMHFlOw+gEQj+X9Pql6UxbaeaSQJ 6qUdftZVSBs6c8EOd9VNrRHB+7yeyKFknQynx3836MiNzTRXUxqQLzHRf lCTaxyjhHCoVqUcGuVqi3HCcicf7ku01sArzyVRuYc0/psQbfz1ATM1Ze Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAJePY1OtJA2D/2dsb2JhbABagwZPV4JnuiiHPoEQFnSCJQEBAQMBAQEBHgFJAwsFBwQCAQgRBAEBAgMGHQIDAiEGCxQJCAIEAQ0FCIglAwkIDYkunBcBnSUNhkUTBIEnihx4gT8nMQcGgmY4gRUEhFkCkF+CBI8GhVuDNIFpQg
X-IronPort-AV: E=Sophos;i="4.97,972,1389744000"; d="scan'208";a="40520029"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 02 May 2014 12:33:54 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s42CXsmx006710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 May 2014 12:33:54 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.212]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 2 May 2014 07:33:53 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: 神明達哉 <jinmei@wide.ad.jp>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
Thread-Index: AQHPZJnNHMzNFfxEIk6wcBa/GM4ndJstOXMQ
Date: Fri, 02 May 2014 12:33:53 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B008430@xmb-rcd-x04.cisco.com>
References: <535FEDAD.5010103@gmail.com> <CAJE_bqen37j5UCsKZj6syVyvk2Xed4V_xGp-t4xY8shjmS+H5g@mail.gmail.com>
In-Reply-To: <CAJE_bqen37j5UCsKZj6syVyvk2Xed4V_xGp-t4xY8shjmS+H5g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.245.71]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/FT_xe_VqMSiP98Z_3QltzUAsG2k
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18
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: <http://www.ietf.org/mail-archive/web/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: Fri, 02 May 2014 12:33:58 -0000
Jinmei: Thanks for your review and feedback. Regarding your first point, there's probably nothing (except the option length limitations, though RFC 3396 handles that) that would prevent this from being adopted for DHCPv4. But it is indeed a question of whether advancing DHCPv4 is as important as advancing DHCPv6. Also, the DHC WG charter is focused on DHCPv6. If this work does advance, and there's sufficient interest, I could well see someone proposing the same for DHCPv4. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of ???? Sent: Wednesday, April 30, 2014 1:30 PM To: Tomek Mrugalski Cc: dhcwg Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 At Tue, 29 Apr 2014 20:21:33 +0200, Tomek Mrugalski <tomasz.mrugalski@gmail.com> wrote: > Since we have upcoming holiday on May 1st (which happens to be a > reason for extended weekend in many parts of Europe) and the topic in > question is not trivial, this WGLC is a bit longer than usual. > > Please send your comments by May 18th 2014. If you do not feel this > document should advance, please state your reasons why. I've read the document. I don't have a particular opinion on whether it should advance, mainly because I'm not a security expert. I have some comments that may hopefully be useful, though: Some higher level points - (maybe already discussed before but) the concept of using public key authentication in DHCP makes some sense to me, but I wonder why we are discussing this specifically for DHCPv6. As far as I know there's no such counterpart in DHCPv4 (the only related thing I can google is draft-gupta-dhcp-auth-02.txt, which expired long ago), am I correct? If so, is that because *v4 is just too legacy and isn't worth improvements anymore? Or does that reflect some DHCP specific points that make public key authentication not so viable? If it's the latter, doesn't it also apply to this proposal? - The description of the draft is a bit vague (which may have to be clarified anyway), but if I understand it correctly, it assumes that both clients (each of them) and servers maintain their pair of public-private keys, and a client offers and uses its own key to authenticate messages from the client to servers. Is that correct? If so, does this make sense? My general understanding is that authenticating DHCP messages from clients to server is not that critical, and it's quite unlikely that servers maintain public keys of all possible clients so the servers would have to rely on the leap-of-faith model. They then may have to worry about the "resource exhaustion attacks" (although I'm not sure if this is a big issue, see below). Other non editorial comments on the draft: - Section 5.1: Public Key A variable-length field containing public key. The key MUST be represented as a lower-case hexadecimal string with the most significant octet of the key first. Typically, the length of a 2048-bit RSA Is there any specific reason it's represented as a string? Not necessarily bad, but I thought more common practice here is to simply use the binary value of the key. DHCP options in wire format are not expected to be human readable anyway, so I don't see the point for using a string here. - In Section 6.2: On the recipient that supports the leap of faith model, the number of cached public keys or unverifiable certificates MUST be limited in order to protect against resource exhaustion attacks. If the This is mainly concerned about servers, correct? If so, I'm not sure how severe this "attacks" are; DHCP servers generally need to maintain some state for each client (unless that's stateless only server) and would naturally already have some limitation on that resource. Shouldn't the general defense be enough for this particular resource, too? (But I was also not sure if it makes sense to use (public key) authentication for messages from clients in the first place; see higher-level discussions above) - Related, it seems some part of Section 6.2 is more specific for clients and some other part is more specific to servers. So it may be helpful if we have separate subsections focusing on these particular cases. Just a suggestion. Editorial nits: - Section 4.3 they may fall back the unsecure model, if both client and server s/fall back the/fall back to the/ (I found the missing 'to' of this kind in several other places in the draft) - Section 4.3 whether to accept the messages. If the client accept the unsecure messages from the DHCPv6 server. The subsequent exchanges will be in unsecure model. s/server. The/server, the/ - Section 4.3 on the server policy. If the server mandidates the authentication, s/mandidates/mandates/ - Section 6.1 messages, MUST contain either a the Public Key or Certificate option, s/a the/the/ (?) - Section 6.2 error status code, defined in Section 5.4, back to the client.. s/.././ -- JINMEI, Tatuya _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Res… Tomek Mrugalski
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ralph Droms
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Liubing (Leo)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Declan Ma
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ralph Droms
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ralph Droms
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Bernie Volz (volz)
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… liuzilong8266
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Sheng Jiang
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ralph Droms
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Tomek Mrugalski
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ralph Droms
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ralph Droms
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ralph Droms
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ted Lemon
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Sheng Jiang
- [dhcwg] WGLC summary for draft-ietf-dhc-sedhcpv6-… Tomek Mrugalski
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… 神明達哉
- Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 -… Ralph Droms
- [dhcwg] Deployment consideration for SeDHCPv6 Sheng Jiang
- Re: [dhcwg] Deployment consideration for SeDHCPv6 神明達哉
- Re: [dhcwg] Deployment consideration for SeDHCPv6 Ralph Droms
- Re: [dhcwg] Deployment consideration for SeDHCPv6 神明達哉
- Re: [dhcwg] Deployment consideration for SeDHCPv6 Sheng Jiang
- Re: [dhcwg] Deployment consideration for SeDHCPv6 Ralph Droms