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

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Wed, 21 Mar 2007 14:45:29 +0100

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 ;)

Now, it would be interesting to see what are exactly the access/service provider requirements at the AN/NAS level in terms of access control, in order to be able to see if such or such solution is OK or not.

AFAIK, as the dsl forum and its "IP Sessions" model seems to be the primary target for such dhcp-based access authentication, a set of security requirement was defined in order to assess potential authentication solutions. Is there any description on how this dhcp-based solution would fulfil these security requirements?

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?

BR,

Lionel

> -----Message d'origine-----
> De : Maglione Roberta [mailto:[email-masked]] 
> Envoyé : mercredi 21 mars 2007 13:56
> À : [email-masked]
> Cc : [email-masked]
> Objet : RE: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt
> 
> Hi All,
> 	I did attend dhc wg session this morning and I have a 
> couple of comments on the discussion that took place on
> draft-pruss-dhcp-auth-dsl-00.txt: from a Service Provider 
> perspective we are interesting, for a DSL scenario, in a 
> simple and scalable solution that is able to speed up the 
> migration from PPP based access model to a pure IP based 
> access model keeping the same functionalities provided by PPP 
> especially in terms of AAA. Main reasons why we are moving 
> from PPP to IP sessions are scalability and "always-on" 
> connections requirements.
> 
> Also looking at the work done in DSL Forum in WT-146 we think 
> DHCP with authentication could be a good candidate approach 
> for this problem and from the preliminary analysis that we 
> did this approach could satisfy the service requirements that 
> we have, at same time we are open to discuss our requirements 
> and compare dhcp with authentication with other possible approaches.
> 
> Thanks,
> Roberta
> 
> --------------------------------------------------------------------
> Roberta Maglione
> Telecom Italia - T.IE.AFT.BI
> Broadband Network Services Innovation
> Via G. Reiss Romoli 274
> 10148 Torino - Italy
> Phone: +39 011 228 5007
> e-mail: [email-masked]
> -------------------------------------------------------------------
> 
> > -----Original Message-----
> > From: Richard Pruss [mailto:ric at cisco.com]
> > Sent: Monday, March 05, 2007 9:57 PM
> > To: Yoshihiro Ohba
> > Cc: dhcwg at ietf.org
> > Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt
> > 
> > Yoshihiro Ohba wrote:
> > > Thank you for the URLs.  But what is missing in my 
> statement while 
> > > especially I mentioned "some level of L3 access control"?  For 
> > > example, "all IP traffic on the port is blocked except for DHCP 
> > > packets" is a form of L3 access control.
> > >
> > So in what you saying is that in addition to the 7 steps of 
> complexity 
> > that your proposal also needs a whole new layer of L3 
> access control 
> > signalling so that once you have achieved the panacea of being PANA 
> > authenticated the L3 access control, which is currently being
> controled
> > by DHCP messages.
> > Sounds to me as if you are just desperately trying to find 
> some real 
> > application for PANA.
> > 
> > Possibly you should consider national border controls for IP as the 
> > perfect PANA application. It seems ill suited to other applications
> but
> > for putting up a random check-point in the middle of the internet
> where
> > you need to present your L3 national passport, PANA seems perfect.
> > 
> > >
> > > I am not sure what is your definition of the term "elegant", but
> IMO,
> > > if it is so elegant, then it should work with stateless 
> IPv6 address 
> > > autoconfiguration as well.
> > >
> > A future revision of this ID will work with DHCPv6, and, yes, I am
> only
> > targeting DHCP-based environments as this is a DHCP-based extension.
> > Stateless autoconfig is out of scope, though of course DHCP-PD with 
> > stateless autoconfig behind an RG would still work here.
> > 
> > Regards,
> > Ric
> > 
> > > Regards,
> > > Yoshihiro Ohba
> > >
> > > On Mon, Mar 05, 2007 at 01:10:08PM +1000, Richard Pruss wrote:
> > >
> > >> I do not think anything your response addresses the elegance
> difference
> > >> but the security point warrants some extra education, 
> your comment
> was:
> > >>
> > >>> With regard to security authorizations, both a) and b) are the
> same in
> > >>> the sense that L2 is fully available for unauthorized 
> subscriber 
> > >>> devices and hence some level of L3 access control is needed to
> keep
> > >>> unauthorized subscriber devices from inevitable abuse, as anyone
> can
> > >>> statically configure an IP address in both cases.
> > >>>
> > >> On the contrary we see that almost all SP's and most Enterprise
> > ethernet
> > >> networks do not allow static IP address allocation as they simply
> use
> > >> DHCP and enforce that users use the address assigned to 
> them. This
> is
> > >> enforced by a host of network features from vendors, the common
> Cisco
> > >> one in routers is DHCP Secured IP Address Assignment.
> > >>
> >
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> 2/122newft
> /1
> > 22t/122t15/ftdsiaa.htm
> > >>
> > >> At the layer 2 edge and in switches the same operation 
> is commonly
> part
> > >> of the DHCP snooping security package and we call it IP Source
> Guard.
> > >>
> >
> http://www.cisco.com/en/US/products/hw/switches/ps4324/product
> s_configur
> at
> > ion_guide_chapter09186a00801cddbc.html#1083306
> > >> To save you ready the URL's the operation in switches is 
> described
> as:
> > >> "
> > >> Initially, all IP traffic on the port is blocked except for DHCP
> > packets
> > >> that are captured by the DHCP snooping process. When a client
> receives
> > a
> > >> valid IP address from the DHCP server, or when a static 
> IP source 
> > >> binding is configured by the user, a per-port and VLAN Access
> Control
> > >> List (PVACL) is installed on the port. This process restricts the
> > client
> > >> IP traffic to those source IP addresses configured in 
> the binding;
> any
> > >> IP traffic with a source IP address other than that in the IP
> source
> > >> binding will be filtered out. This filtering limits a host's
> ability to
> > >> attack the network by claiming a neighbor host's IP address.
> > >> "
> > >>
> > >> With our customers' networks under constant attack we are under
> > constant
> > >> pressure to deliver features that ensure and audit behaviour that
> was
> > >> once accepted on trust.
> > >>
> > >> Cheers,
> > >> Ric
> > >>
> > >> Yoshihiro Ohba wrote:
> > >>
> > >>> On Mon, Mar 05, 2007 at 10:33:28AM +1000, Richard Pruss wrote:
> > >>>
> > >>>
> > >>>> On one hand;
> > >>>> a) we can authenticate before allocating an subscriber IP
> address,
> > host
> > >>>> configuration and network edge configuration and security
> > authorizations.
> > >>>>
> > >>>> Or.
> > >>>> b1)On the other we can allocate a temporary subscriber IP
> address,
> > host
> > >>>> configuration for a temporary context and network edge
> configuration
> > for
> > >>>> a totally unknown user and security authorizations for someone
> who
> > know
> > >>>> nothing about and somehow secure the layer 2 
> multi-point network
> they
> > >>>> are on from the inevitable abuse.
> > >>>>
> > >>>>
> > >>> Temporal host configuration and network edge 
> configuration happens 
> > >>> locally between the HGW and NAS without AAA 
> interaction.  Also, I 
> > >>> think that the network edge configuration for unauthorized
> subscriber
> > >>> devices can be statically configured on the NAS (e.g., always 
> > >>> disabling IP forwarding for a pool of temporal IP addresses.)
> > >>>
> > >>> With regard to security authorizations, both a) and b) are the
> same in
> > >>> the sense that L2 is fully available for unauthorized 
> subscriber 
> > >>> devices and hence some level of L3 access control is needed to
> keep
> > >>> unauthorized subscriber devices from inevitable abuse, as anyone
> can
> > >>> statically configure an IP address in both cases.
> > >>>
> > >>>
> > >>>
> > >>>> b2)Then you can renew the DHCP lease every 60 seconds 
> putting an
> > extra
> > >>>> load on everything involved.
> > >>>>
> > >>>>
> > >>> This is not needed if the client is authenticated within 60
> seconds.
> > >>>
> > >>>
> > >>>
> > >>>> b3) You authenticate with PANA
> > >>>> b4) You remove all the network edge configuration for now known
> user
> > and
> > >>>> security authorizations and install new network edge
> configuration
> > and
> > >>>> security authorizations.
> > >>>>
> > >>>>
> > >>> The installation part is commont to a) and b).  As I mentioned
> above,
> > >>> I think that the network edge configuration for an unauthorized 
> > >>> subsciber device can be statically configured and does 
> not have to
> be
> > >>> removed.
> > >>>
> > >>>
> > >>>
> > >>>> b5) You wait for the user to renew.
> > >>>> b6) You reject that.
> > >>>> b7) Wait for the user to discover
> > >>>>
> > >>>>
> > >>> b5), b6) and b7) can be replaced with server-initiated 
> DHCP force 
> > >>> renew procedure.
> > >>>
> > >>>
> > >>>
> > >>>> b8) You allocating an subscriber IP address and host
> configuration
> > based
> > >>>> on what you installed in B4 and the MAC address in 
> DHCP Discover.
> > >>>>
> > >>>>
> > >>> This is common to a) and b).
> > >>>
> > >>>
> > >>>
> > >>>> I think the elegance of approach a) verses b1-7) is 
> pretty clear,
> > >>>>
> > >>>>
> > >>> It is not clear to me if a) is elegant.  The only 
> difference I can
> see
> > >>> (modulo the difference in authentication protocols) is one
> additonal
> > >>> DHCP before authentication and without AAA interaction in b).
> This
> > >>> difference seems trivial to me.  Also, I am not sure 
> how a) works
> when
> > >>> stateless IPv6 address autoconfiguration for IP address
> configuration.
> > >>>
> > >>> Regards,
> > >>> Yoshihiro Ohba
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> Ric
> > >>>>
> > >>>> Yoshihiro Ohba wrote:
> > >>>>
> > >>>>
> > >>>>> 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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >
> > >
> >
> --------------------------------------------------------------------
> 
> CONFIDENTIALITY NOTICE
> 
> This message and its attachments are addressed solely to the 
> persons above and may contain confidential information. If 
> you have received the message in error, be informed that any 
> use of the content hereof is prohibited. Please return it 
> immediately to the sender and delete the message. Should you 
> have any questions, please contact us by replying to 
> [email-masked].
> 
>         Thank you
> 
>                                         www.telecomitalia.it
> 
> --------------------------------------------------------------------
>                         
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Mar 2007 15:12:44 +0100

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.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 21 Mar 2007 18:18:35 +0100

> transitional protocol, not a solution.   

Unfortunately, most solutions don't stay that way. Once DHCP is out there as
a network access authentication protocol, it will be used to the full extent
and get extended everywhere (SDOs, vendors, etc.).

> So what I really want to
> know is, is this document considered useful *without* the EAP stuff?

If we ask about "usefulness", I'm sure there will always be some people no
matter what carries CHAP or EAP (IP, ARP, router discovery, Neighbor
discovery, Mobile IP, avians, etc...). 

I think we shall ask instead: 
- Why do we need another solution as IETF when we have PANA?
- Is DHCP the right protocol to use?

Alper

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Mar 2007 18:31:30 +0100

On Mar 21, 2007, at 6:18 PM, Alper Yegin wrote:
> matter what carries CHAP

Alper, I was asking specifically because I wanted to know if removing  
EAP made the protocol useless.   I didn't want to know if anybody  
considered the protocol useful in general; obviously someone does, or  
it wouldn't have been proposed.

---

From: Richard Pruss <[email-masked]>
Date: Thu, 22 Mar 2007 04:19:26 +1000

> access to the network using the DHCP protocol.
I did say this as a comment to Dave's excellent presentation but let me 
try it on list as well.
Some switch implementations allow administrative policy that enforces 
that hosts use DHCP on particular ports, and any host that successfully 
uses DHCP (as determined by the DHCP server policy) is allowed on the 
network. Additionally these switches enforce that the host use the 
address assigned through DHCP, and not some other address.  Then 
additionally to that some switches enforce not only the use of the 
assigned address on a port but also enforce the binding between the 
layer 2  and the IP address.

The effect of these features in relatively commonly deployed in first 
hop switches is that the DHCP exchange does effectively control access 
in the definition Dave gave for access control.  Which is access too 
things beyond the point of enforcement in this case this is layer 2 
access contro and access to things beyond the first hop layer 2 port.

Regards,
Ric

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Mar 2007 21:33:24 +0100

On Mar 21, 2007, at 7:19 PM, Richard Pruss wrote:
> The effect of these features in relatively commonly deployed in  
> first hop switches is that the DHCP exchange does effectively  
> control access in the definition Dave gave for access control.   
> Which is access too things beyond the point of enforcement in this  
> case this is layer 2 access contro and access to things beyond the  
> first hop layer 2 port.

That's true, but nevertheless you can't say that the protocol you  
have proposed does access control.   It may have the side effect of  
doing access control if you happen to use these switches, but that's  
just a side effect.  You'd get the same effect if you weren't doing  
the authentication step this way, because access is granted simply as  
a side effect of the DHCP exchange.

I think it confuses things massively to talk about this as an access  
control protocol.   That's why I wrote what I wrote earlier.   This  
protocol simply authenticates an identifier you are using to  
determine what parameters to assign the client and what range you  
pull its address from, using AAA authentication.   The access control  
bit is a side issue that will just draw you into a rathole, and I  
don't think it's a useful part of the sales pitch for your  
protocol.   Your protocol works and is useful completely independent  
of this side effect, so why talk about the side effect?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 22 Mar 2007 05:32:54 -0400

> +AAA configuration system to a DHCP-based configuration system.

If we discuss transitional aspect, use of PANA with EAP-MD5 between
HGW and NAS provides a smooth transition.  This was explained in
details at he beginning of this thread:

http://www1.ietf.org/mail-archive/web/dhcwg/current/msg07035.html

Yoshihiro Ohba

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 22 Mar 2007 05:54:11 -0400

I think the problem with using PANA is that the communication between HG
or CPE and the NAS is problematic. A few of us had a hallway decision
with Alper about using PANA and it sounded good until we looked a bit
further into how the communication between HG/CPE and NAS could be
accomplished (Alper had left by then, so he was not able to help us
understand how this would work).

But, I'm *NOT* an expert in this space and gladly defer to others. 

- Bernie

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 5:33 AM
To: Ted Lemon
Cc: DHC WG
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 22 Mar 2007 11:27:20 +0100

Bernie,

> understand how this would work).

Can you or someone else tell us the issue?

To DHC WG: It does not make sense trying to design a new solution before
understanding the requirements and whether the current solutions work. 

Thanks.

Alper