Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt

Ted Lemon <Ted.Lemon@nominum.com> Wed, 21 March 2007 14:13 UTC

Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Yl-0006Ze-GZ; Wed, 21 Mar 2007 10:13:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU1Yk-0006ZU-GD for dhcwg@ietf.org; Wed, 21 Mar 2007 10:13:02 -0400
Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU1Yi-0005De-Nc for dhcwg@ietf.org; Wed, 21 Mar 2007 10:13:02 -0400
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 5FE6A568E8 for <dhcwg@ietf.org>; Wed, 21 Mar 2007 07:13:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4 tests=AWL: 0.146,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW, TOTAL_SCORE: 4.216
X-Spam-Level:
Received: from [130.129.18.76] ([130.129.18.76]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for dhcwg@ietf.org; Wed, 21 Mar 2007 07:12:56 -0700
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02604662C8D@FTRDMEL2.rd.francetelecom.fr>
References: <7DBAFEC6A76F3E42817DF1EBE64CB02604662C8D@FTRDMEL2.rd.francetelecom.fr>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <A5958207-D564-476D-8A2A-428CDDD1BB92@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt
Date: Wed, 21 Mar 2007 15:12:44 +0100
To: DHC WG <dhcwg@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
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>
Errors-To: dhcwg-bounces@ietf.org

On Mar 21, 2007, at 2:45 PM, MORAND Lionel RD-CORE-ISS wrote:
> So at least, it seems that there is consensus that something is  
> missing in dhcp-based environment for network access control, that  
> was not (really) the case several months ago ;)

I don't think you can say that.   Dave Thaler actually made a really  
nice presentation this morning about his configuration draft, and one  
of the points he reiterated, which has been a theme for the DHCP  
community pretty much since day one, is that you *can't* control  
access to the network using the DHCP protocol.

The reason that I think that the CHAP-over-DHCP option has merit is  
because it's being used to authenticate not network access itself,  
but rather the identifier that is being used to control the specific  
parameter set assigned to the client.   Nothing about this protocol  
is actually an access control mechanism other than by accident - if  
you can't provide valid identification for your configuration key,  
the server can't give you a configuration.   You can still manually  
configure; it probably won't work because stuff happening at layers  
two and three won't get configured by the NAS.   But fundamentally  
this isn't an access control system - it's a system for matching an  
authenticated key to a configuration.   It only controls access if  
other elements in the network that aren't described in this draft  
(and should not be) effect some sort of access control.

> Finally, I have a specific question: should the dhcp-based  
> authentication solution be considered either as a "patch" solution  
> for dhcp-based dsl networks, fulfilling some short-term security  
> requirements not covered by other solutions, or as the ultimate  
> solution for providing network access control in any dhcp-based  
> environment?

As a disinterested third party, my opinion is that this is a  
transitional protocol, not a solution.   I think it should be  
presented that way, not as a final answer to the authentication  
problem.   The WG has been down the path of doing PANA and EAP over  
DHCP in the past, and we've never gotten to the point of seeing a  
proposal that we could make sense of; if you take away all the EAP  
baggage from this suggestion, it seems reasonable to me, but it does  
not seem like a solution to the network access problem - it seems  
like a solution to the problem of making the transition from a PPPoE 
+AAA configuration system to a DHCP-based configuration system.



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg