Re: [dhcwg] questions about DHCPv6 authentication
Christian Strauf <strauf@uni-muenster.de> Thu, 17 June 2004 11:14 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 HAA19406; Thu, 17 Jun 2004 07:14:43 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bauez-00087b-AH; Thu, 17 Jun 2004 07:02:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BauYQ-0005Un-5Q for dhcwg@megatron.ietf.org; Thu, 17 Jun 2004 06:55:34 -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 GAA17776 for <dhcwg@ietf.org>; Thu, 17 Jun 2004 06:55:31 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BauYL-0002HF-0y for dhcwg@ietf.org; Thu, 17 Jun 2004 06:55:29 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BauXB-0001o3-00 for dhcwg@ietf.org; Thu, 17 Jun 2004 06:54:18 -0400
Received: from kummerog.uni-muenster.de ([128.176.184.156]) by ietf-mx with esmtp (Exim 4.12) id 1BauW9-0001OM-00 for dhcwg@ietf.org; Thu, 17 Jun 2004 06:53:14 -0400
Received: by kummerog.uni-muenster.de (Postfix, from userid 1000) id 08F6B27466; Thu, 17 Jun 2004 12:53:18 +0200 (CEST)
Date: Thu, 17 Jun 2004 12:53:18 +0200
From: Christian Strauf <strauf@uni-muenster.de>
To: dhcwg@ietf.org
Subject: Re: [dhcwg] questions about DHCPv6 authentication
Message-ID: <20040617105317.GB11343@kummerog.uni-muenster.de>
References: <y7v1xkeabz8.wl@ocean.jinmei.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <y7v1xkeabz8.wl@ocean.jinmei.org>
User-Agent: Mutt/1.5.6i
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-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
Excuse possible dupes, I had trouble with my mailer. Jinmei-san, > 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"? the key distribution is done out-of-band, as stated in section 21.4.3. Therefore, no inital exchange for key distribution is necessary. The way I understand this section is that clients must keep using the same key they've been using for any previous message exchange that included an authentication option. Stateless DHCPv6 clients are free to use authentication options with pre-shared keys the same way that RFC3315 clients do. > 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? Yes, partly. I think the part that is contradictory is "[...] or pass the validation test [...]". This section clearly -- as you correctly identified in my eyes -- contradicts the quoted part of 21.4.2 above. I agree that a failed validation test is very critical and should not be open to local policy (i.e. no responses to these advertise messages should be made by the client in any case). The other part ("[...] no Advertise messages include authentication information [...]") may indeed be a matter of local policy. > 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? I think that it doesn't contradict section 21.4.2 but as a matter of fact is a logical consequence if validation tests fail. However, I agree 100% that this is a potentially dangerous behaviour because it can be used for DoS attacks on servers and clients. I think that this deserves to be addressed in the Security Considerations section because appropriate timeouts or similar should be in place to prevent this kind of attack by malicious hosts that send malformed replies that will fail validation tests. > Any hints or answers would be highly appreciated. Thanks in advance, I hope that you find my comments useful. Christian _______________________________________________ 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