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

[Richard Pruss <ric at cisco.com>]

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