[dhcwg] questions about DHCPv6 authentication
JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Thu, 17 June 2004 12:27 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24347; Thu, 17 Jun 2004 08:27:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BavnY-0008Nb-Ce; Thu, 17 Jun 2004 08:15:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaEom-0007iv-Mp for dhcwg@megatron.ietf.org; Tue, 15 Jun 2004 10:21:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20890 for <dhcwg@ietf.org>; Tue, 15 Jun 2004 10:21:39 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaEol-0002VZ-Sb for dhcwg@ietf.org; Tue, 15 Jun 2004 10:21:39 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaEnm-00026F-00 for dhcwg@ietf.org; Tue, 15 Jun 2004 10:20:39 -0400
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1BaEmi-0001i7-00 for dhcwg@ietf.org; Tue, 15 Jun 2004 10:19:48 -0400
Received: from ocean.jinmei.org (unknown [2001:200:0:8002:200:39ff:fe5e:cfd7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8F7A11525D for <dhcwg@ietf.org>; Tue, 15 Jun 2004 23:19:30 +0900 (JST)
Date: Tue, 15 Jun 2004 23:19:35 +0900
Message-ID: <y7vfz8wc39k.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: dhcwg@ietf.org
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
X-Mailman-Approved-At: Thu, 17 Jun 2004 08:15:13 -0400
Subject: [dhcwg] questions about DHCPv6 authentication
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Hello, I have a couple of questions on DHCPv6 authentication described in RFC3315 (Section 21). 1. the RFC says in 21.4.4.4 as follows: 21.4.4.4. Sending Information-request Messages If the server has selected a key for the client in a previous message exchange (see section 21.4.5.1), the client MUST use the same key to generate the authentication information throughout the session. I don't really understand this part...does this assume a separate Solicit-Advertise (or Reply if rapid-commit option is used?) exchanges to negotiate the key? If so, what if the server and/or the client only implement the "stateless" subset described in RFC3736? Note that RFC3736 says: Authenticated DHCP, as described in sections 21 and 22.11 of the DHCP specification [1], can be used to avoid attacks mounted through the stateless DHCP service. I read this to mean that Authenticated DHCP can be used for implementations only support RFC3736. But how can such implementations select the key without the "previous message exchange"? 2. RFC3315 says in Section 21.4.2 (Message Validation) that If the MAC computed by the receiver does not match the MAC contained in the authentication option, the receiver MUST discard the DHCP message. It seems to me this part of the specification some other parts of Section 21.4: 2-1) in Section 21.4.4.2, the RFC allows the client to respond to an Advertise even if it fails on authentication: Client behavior, if no Advertise messages include authentication information or pass the validation test, is controlled by local policy on the client. According to client policy, the client MAY choose to respond to an Advertise message that has not been authenticated. Doesn't this contradict with Section 21.4.2? 2-2) this can be a more serious issue. The RFC says in Section 21.4.4.4 that: If the Reply fails to pass the validation test, the client MUST restart the DHCP configuration process by sending a Solicit message. Doesn't this contradict with Section 21.4.2? Moreover, it seems to me that restarting the configuration process in this case can open up a possibility of DoS attack. What is the background of this specification? Any hints or answers would be highly appreciated. Thanks in advance, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] questions about DHCPv6 authentication JINMEI Tatuya / 神明達哉
- Re: [dhcwg] questions about DHCPv6 authentication Christian Strauf
- [dhcwg] questions about DHCPv6 authentication JINMEI Tatuya / 神明達哉
- Re: [dhcwg] questions about DHCPv6 authentication JINMEI Tatuya / 神明達哉
- Re: [dhcwg] questions about DHCPv6 authentication Christian Strauf