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

[Yoshihiro Ohba <yohba at tari.toshiba.com>]

Before authentication, it is possible for the NAS to assign a
temporary IP address (for which IP forwarding is restricted) to the
subscriber device using DHCP.  Once PANA authentication succeeds, the
NAS has obtained subscriber-specific client configuration information
and other authorization parameters from the AAA infrastructure.  After
that, DHCP reconfiguration can be made using the subscriber-specific
client configuration information to allow the subscriber device to
change its IP address from the temporary one to the fully authorized
one.  Please refer to draft-morand-pana-panaoverdsl for more
information.

Yoshihiro Ohba


On Mon, Mar 05, 2007 at 09:04:17AM +1000, Richard Pruss wrote:
> Possibly it would help you understand if you though of why the NAS
> authenticates the subscriber; from section 3.1 of the draft
> "
> The NAS obtains per-subscriber client
> configuration information either locally or from the AAA
> infrastructure (which itself may consult external DHCP servers if
> necessary) after authentication is successfully completed.
> "
> In wholesale DSL networks it is common to use the @domain portion of the
> username to find retail ISP of the subscriber, they are then
> authenticated by that ISP's AAA. This authentication returns
> authorizations which in conjunction with the wholesale configuration in
> the NAS determines the subscriber IP address, host configuration and
> network edge configuration and security authorizations which is all
> closely coupled to the retail domain.
> From this perspective, PANA happens to late as the host already has it's
> IP address, it would be in the correct IP forwarding context, the
> network would already need to have some mechanisms for securing the
> domain from layer 3 attacks independent of PANA and so on.
> 
> Regards,
> Ric
> 
> Yoshihiro Ohba wrote:
> > 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 at ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> >
> >   
> 

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