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

Yoshihiro Ohba <yohba@tari.toshiba.com> Fri, 02 March 2007 20:28 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 1HNEN0-0005sa-VS; Fri, 02 Mar 2007 15:28:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEN0-0005sU-2Q for dhcwg@ietf.org; Fri, 02 Mar 2007 15:28:50 -0500
Received: from imx12.toshiba.co.jp ([61.202.160.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNEMy-0006yh-DD for dhcwg@ietf.org; Fri, 02 Mar 2007 15:28:50 -0500
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx12.toshiba.co.jp with ESMTP id l22KSluk016554 for <dhcwg@ietf.org>; Sat, 3 Mar 2007 05:28:47 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp id l22KSkLM004412; Sat, 3 Mar 2007 05:28:46 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with ESMTP id FAA04411; Sat, 3 Mar 2007 05:28:46 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id l22KSjX3026809; Sat, 3 Mar 2007 05:28:46 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id l22KSjUv017884; Sat, 3 Mar 2007 05:28:45 +0900 (JST)
Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0JEA004TGM7VDKG0@mail.po.toshiba.co.jp>; Sat, 03 Mar 2007 05:28:45 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.63) (envelope-from <yohba@tari.toshiba.com>) id 1HNEMu-0003Ww-Cn; Fri, 02 Mar 2007 12:28:44 -0800
Date: Fri, 02 Mar 2007 15:28:44 -0500
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
To: dhcwg@ietf.org
Message-id: <20070302202844.GC8479@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset="iso-2022-jp"
Content-disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Subject: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt
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

Hi,

Let me ask the same fundamental question that I asked before for a
similar draft related to DHCP and authentication.

Is this WG chartered for developing a solution for network access
authentication and authorization other than developing authentication
mechanisms for DHCP?

I am asking this because Introduction of
draft-pruss-dhcp-auth-dsl-00.txt says:

"
   This document defines DHCP Options and procedures that allow for a
   CHAP-based authentication exchange to occur in DHCP in order to
   enable smooth migration from PPP sessions to IP sessions in a DSL
   Broadband network environment.  Primary goals are integration of
   authentication in such a way that it will operate seamlessly with
   existing RADIUS-based AAA infrastructure and ATM or Ethernet based
   DSL Networks.  As such, only the termination points of PPP in the DSL
   network are affected, both of which are devices that would logically
   need to be updated in any transition from PPP to IP sessions.
"

Also, I fail to see a reason for IETF to work on combining DHCP and
network access authentication even as experimental and for the purpose
of the primary goals stated above.  I believe that the primary goals
can be achieved by simply using PANA running EAP-MD5 between HGW and
NAS.  In this case, NAS is acting as EAP authenticator co-located with
EAP server for EAP-MD5, where the EAP server is acting as a protocol
translator that converts credentials carried in EAP-MD5 into RADIUS
attributes or field (i.e., CHAP-Password and CHAP-Challenge or RADIUS
Request Authenticator field) used for carrying CHAP credentials, and
vise versa.  If an algorithm other than MD5 is used for CHAP, it is
also possible to define an experimental EAP method to interwork with
non-MD5 CHAP algorithms and again let the EAP server on the NAS act as
a protocol translator.  I think these workarounds are sufficient to
work with existing RADIUS-based AAA infrastructure and ATM or Ethernet
based DSL Networks and still allows smooth migration from PPP session
to IP session with EAP.

The bottomline is, host configuration and network access
authentication are two different problems that are better solved by
separate protocols.

Regards,
Yoshihiro Ohba

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