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

From: "Maglione Roberta" <[email-masked]>
Date: Wed, 21 Mar 2007 13:55:42 +0100

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/ios122/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/products_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

---

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

What did you think about the question of supporting EAP?   Does that  
serve any useful purpose to you?

---

From: "Maglione Roberta" <[email-masked]>
Date: Wed, 21 Mar 2007 15:37:51 +0100

Having EAP would add more flexibility
Thanks,
Roberta

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 2:16 PM
To: Maglione Roberta
Cc: DHC WG
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

From: "pavan_kurapati" <[email-masked]>
Date: Wed, 21 Mar 2007 21:07:14 +0530

I am not sure what was discussed in the WG regarding supporting EAP as I didnt attend the meeting. But some access nodes (DSLAMs) support EAP for the transition from PPP environment. I think the only problem with this approach is that DSLAM needs to authenticate the subscribers (or approach AAA server). Generally it is preferred to have authentication mechanisms to be done between NAS and the subscriber instead of DSLAM doing it. In the networks where authentication is preferred at the NAS usage of EAP might not be possible. So I like this idea of supporting authentication mechanism through DHCP.

Thanks,
Pavan Kurapati

________________________________

From: Ted Lemon [mailto:[email-masked]]
Sent: Wed 3/21/2007 6:46 PM
To: Maglione Roberta
Cc: DHC WG
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Mar 2007 16:46:20 +0100

> serve any useful purpose to you?

I should have been more clear about why I was asking the question.    
I think that the part of this document that describes a way of doing  
EAP over DHCP is a non-starter.   Basically, this document completely  
breaks DHCP in order to implement EAP.   So what I really want to  
know is, is this document considered useful *without* the EAP stuff?

---

From: "Maglione Roberta" <[email-masked]>
Date: Wed, 21 Mar 2007 17:47:55 +0100

As I said before we are looking for a mechanism to migrate PPP to IP
sessions keeping the same functionalities provided by PPP an
authentication is one of those functionalities: so going in this
direction I think the document could be useful. I'm not in the position
to answer right now the question of which of the two options described
in the document is better this would require more accurate comparison
analysis.
 
Thanks 
Roberta

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 4:46 PM
To: DHC WG
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it

---

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

Ted Lemon wrote:
> I should have been more clear about why I was asking the question.   I 
> think that the part of this document that describes a way of doing EAP 
> over DHCP is a non-starter.   Basically, this document completely 
> breaks DHCP in order to implement EAP.   So what I really want to know 
> is, is this document considered useful *without* the EAP stuff?
Ted could you possibly educate me on what the got broken.  The both 
options have state machine implications on both the server and client.   
The second option constrains those effects to new messages to handle the 
EAP in a series of messages but beyond that DHCP exchange occurs as 
normal.   This lends me to suspect that option 2 may constrain its 
effect on the majority current DHCP implementation by limiting the 
additional effort to handling additional messages.

Regards,
Ric

---

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

On Mar 21, 2007, at 7:35 PM, Richard Pruss wrote:
> options have state machine implications on both the server and  
> client.   The second option constrains those effects to new  
> messages to handle the EAP in a series of messages but beyond that  
> DHCP exchange occurs as normal.   This lends me to suspect that  
> option 2 may constrain its effect on the majority current DHCP  
> implementation by limiting the additional effort to handling  
> additional messages.

In your presentation you said that the main reason you went to a six- 
way handshake, and the entire reason you added the EAP-specific  
messages, was because someone told you that the protocol didn't make  
sense without EAP.   Correct me if I am wrong about this - I'm just  
repeating what you said.

Both protocols you proposed were broken in that they require six-way  
handshakes, and one requires adding an entirely new set of messages  
to the DHCP protocol.   Your proposed protocol doesn't add enough  
value to justify a change of this type - indeed, I can't imagine  
*any* protocol that would, for DHCPv4.   DHCPv4 is a mature protocol  
- changing the fundamental packet exchange at this point is a non- 
starter.   Changing it to make a transitional protocol work is even  
more non-starty than that.

It seemed, based on our back-and-forth today in the WG meeting, that  
you could make the protocol work with a four-way handshake.   The way  
you'd do this would be for the client to present its credentials in  
the DHCPDISCOVER.   The server would use those credentials to get the  
client configuration out of the AAA server without authentication.    
The server would then send a challenge in the DHCPOFFER, and the  
client would send a response in the DHCPREQUEST.   If the response  
validated, the server would respond with a DHCPACK; if not, it would  
respond with a DHCPNAK.   Because the configuration information isn't  
secret, sending it in the DHCPOFFER prior to authenticating the  
client is okay, and you haven't opened a security hole, because the  
client doesn't get a DHCPACK until the authentication succeeds.

---

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

I agree with Ted here. Of course, the main problem with this solution is
the requirement to change the AAA to allow you to obtain the data you
need BEFORE having the user's password?

And, I'd go a bit further to say you already have the option you need to
communicate this information - the DHCP Auth option [RFC 3118].

Yes, you have to write a new draft that documents new Protocol and
Algorithm fields and what the "Authentication Information" contains. But
no new option is needed. No DHCP state machine changes are needed.

Your draft has two options:
1. DHCP Authentication Protocol which communications two values -
Authentication Protocol and Algorithm.
2. DHCP Authentication Data

These map very well into the existing RFC 3118 Auth option.

You might want to reference RFC 3318 Reconfigure Key Authentication
Protocol as in the Auth data it has a flag that indicates whether the
passed value is a key or digest (see 21.5.1). In your case, you might
have 3 or 4 "type" values:
1. Username (sent in DHCPDISCOVER) ... Data in remainder of auth field
is the username.
2. Challenge (sent in DHCPOFFER) ... Data in remainder of auth field is
the CHAP challenge
3. Challenge-Response (sent in DHCPREQUEST) ... Data in remainder of
auth field is the CHAP response.
4. ? (is something needed in DHCPACK? Perhaps not has if
challenge-response isn't valid, a DHCPNAK would be returned?)

Perhaps you just use your "DHCP Authentication Data Option"'s "data"
(Chap Code, Identifier, Data) as the auth data in the RFC 3118
"Authentication Information".

- Bernie

---

From: "Derek Harkness" <[email-masked]>
Date: Thu, 22 Mar 2007 09:40:55 -0000

> Of course, the main problem with this solution is

Plus you need to change, or at least change the usage of, the RADIUS
protocol to allow you to make an access request to get an access accept
for the user data ( IP Address, DNS, etc ) without the valid password
and then another ( access request ) to the server which can return an
Access accept ( carry on as before ) or an Access Reject in which case
this reject applies not to the associated request but to the previous
for that user. 

=> Which doesn't really meet the original requirement of using the same
AAA server infrastructure and associated back end functions, proxy
radius etc. 

Cheers,

	Derek.

+=============================+
Derek Harkness
Juniper Networks 
Nymphenburger Strasse 13-15
80335 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 172 843 6621
Email: [email-masked]
+=============================+ 

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: 22 March 2007 10:25
To: Ted Lemon; [email-masked]
Cc: DHC WG
Subject: RE: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt

- Bernie

---

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

Right, but changing DHCP (and the DHCP state machine) is also a fairly
significant change.

Note that RADIUS offerings already have to have the functionality to be
able to retrieve a user's data without having the user's password. This
is of course not a IETF standardized mechanism but a vendor-specific
solution. As the DHCP server would have to change to support this new
authentication protocol, there's nothing that says it can't access the
user's data through this mechanism (instead of using the RADIUS protocol
to do it).

I don't think there was a stated requirement that the DHCP server <->
RADIUS server interaction *HAD* to happen over RADIUS -- the requirement
is just to use that existing data.

The final authentication step (after receiving the DHCPREQUEST) could
use either the RADIUS protocol or continue to use this vendor-private
communication mechanism.

- Bernie 

-----Original Message-----
From: Derek Harkness [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 5:41 AM
To: Bernie Volz (volz); Ted Lemon; [email-masked]
Cc: DHC WG
Subject: RE: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt

Cheers,

	Derek.

-----Original Message-----
From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: 22 March 2007 10:25
To: Ted Lemon; [email-masked]
Cc: DHC WG
Subject: RE: [dhcwg] draft-pruss-dhcp-auth-dsl-00.txt

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Mar 2007 11:22:58 +0100

> this reject applies not to the associated request but to the previous

The more I hear about this the worse it sounds.   You're talking  
about doing address allocation out of the RADIUS server?   That's  
crazy talk.   Why even bother to use DHCP if you're not actually  
using DHCP?

So let's draw a distinction here.   There is the entire protocol that  
you propose to implement, which I think the working group really  
can't get behind, even if someone outside of DHC says there's a  
demand for it.   And then there is a partial transition solution,  
which lets you use the shared keys you've already established in AAA,  
but doesn't break the DHCP protocol and doesn't do address allocation  
out of RADIUS.

If this partial solution is of interest to you, I'm willing to talk  
about it and help you to make it happen.   I don't know if it's  
practical, and I'm not asserting it is - I'm just saying that if  
there is a pony in here, that's where I think it is.

If the only thing that's "good enough" is the one where you  
authenticate through AAA before you get configuration parameters, and  
do IP address allocation out of AAA, then I am reluctant to help you  
with it, because (a) I think there's zero chance of it passing last  
call in the working group - I would vote against it, and I can't  
think of anybody else in the working group who wouldn't - and (b) it  
breaks RFC2131/2132 in fundamental ways that I don't think are  
acceptable.

I think if you implement the complete solution you've proposed, what  
you have isn't DHCP anymore - it's something using the DHCP port and  
packet structure that will break interoperability in surprising  
ways.   So if that's what you really want, I'd rather see you roll a  
different protocol, call it something different, and think about how  
to advance it on those terms.

---

From: Richard Pruss <[email-masked]>
Date: Thu, 22 Mar 2007 20:24:32 +1000

Ted Lemon wrote:
>> client.   The second option constrains those effects to new messages 
>> to handle the EAP in a series of messages but beyond that DHCP 
>> exchange occurs as normal.   This lends me to suspect that option 2 
>> may constrain its effect on the majority current DHCP implementation 
>> by limiting the additional effort to handling additional messages.
>
> In your presentation you said that the main reason you went to a 
> six-way handshake, and the entire reason you added the EAP-specific 
Happy to clarify what I said.  What I said was that some people I
respect have educated me that making a protocol change that just
addresses the migration is short sighted as the MD5 underlying that CHAP
transactions is now viewed to have security shortcomings.  They simply
pointed out that doing this with EAP allows CHAP interoperation with the
current SP databases but it gives the option of a second step as a
possible third migration of CHAP to something better over EAP.

Saying the protocol does not make sense without EAP is overstating it
slightly, I think it may be better said that when doing the credential
exchange we should have a good reason for not doing EAP.
> handshakes, and one requires adding an entirely new set of messages to 
> the DHCP protocol.   Your proposed protocol doesn't add enough value 
> to justify a change of this type - indeed, I can't imagine *any* 
> protocol that would, for DHCPv4.   DHCPv4 is a mature protocol - 
> changing the fundamental packet exchange at this point is a 
> non-starter.   Changing it to make a transitional protocol work is 
> even more non-starty than that.
I agree that DHCPv4 is mature and as such one needs to discuss with
respect changes in the community with implementations that may be
effected. That said my sense of the community is the interest and
activity on DHCPv4 and v6 implementations is that DHCP is not a moribund
static area.  Far from moribund that we seem to have a active vibrant
community with many implementations doing many interesting things.  As
for the cost of change, that is offset here by the Service Providers
desire to implement services in the layer 2 area of the network that is
not currently possible with PPPoE.
> secret, sending it in the DHCPOFFER prior to authenticating the client 
> is okay, and you haven't opened a security hole, because the client 
> doesn't get a DHCPACK until the authentication succeeds.
I agree what would bring the protocol more closely inline with exisiting
DHCP messages but the AAA servers would need to be changed to provide
information in the way you suggest.  Your proposal though means that we
need to change both the HGW and NAS DHCP implementations and the SP's
AAA implementation.

-Ric

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Mar 2007 11:31:15 +0100

On Mar 22, 2007, at 11:19 AM, Richard Pruss wrote:
> I agree what would bring the protocol more closely inline with  
> exisiting DHCP messages but the AAA servers would need to be  
> changed to provide information in the way you suggest.  Your  
> proposal though means that we need to change both the HGW and NAS  
> DHCP implementations and the SP's AAA implementation.

That's right.   But you only have to change those implementations,  
not the DHCP protocol itself.   The DHCP protocol is used in more  
places than just the interaction between HGW and NAS at broadband  
ISPs.   Broadband ISP network development is done by smart people  
like us.   DHCP end users don't even know what an IP packet looks  
like or how it gets from their computer to the DHCP server - to them,  
a DHCP protocol problem translates into the single bit: "the network  
isn't working."   And they have nobody to call to debug it - all they  
can do is reboot and hope the problem goes away.   So I'm very  
sympathetic to the idea of easing the transition your customers face,  
but I also have to be protective of those other customers.

---

From: "Markus Stenberg \(mstenber\)" <[email-masked]>
Date: Thu, 22 Mar 2007 19:17:01 +0800

Disclaimer: I am using broken mail client - I know it, you know it, no comments please :)

That said..

>more non-starty than that.

I think you are also missing something; there is also the user experience consideration. DHC in general is aimed so that it would work without any user configuration (For obvious reasons); therefore, if you plug onto random network, you CANNOT send your identify in the first message (for example, I have authentication requiring networks at home, the company I work for, and in the university where I sometimes study), at least, not without divulging all these affiliations and having them preconfigured somewhere, and I'd rather not go there. 

Therefore, general-purpose access solution will have to have first _reply_ from the server just indicate capability, as well as the domain to authenticate yourself for, and after that you need to do the exchange. In case of DHC, server cannot provide user-specific stuff in the first message without knowing who the user is, so things break.

The question I would like to ask is this: with PANA (.. some day..) and 802.1x and whatever else out there, why are we reinventing the wheel badly on top of protocol that shouldn't do this part anyway? 802.1x wasn't even mentioned in the DHC WG, despite being actually currently most deployed (XP, Vista, MacOS X, about anything you want to name it) link _authentication_ protocol. In my home systems, I use ethernet all the way; why not replace PPPoE with 802.1x in the general case? I thought that was the typical DSL case as well.

Limiting applicability only to 'some home router configurations in old PPPoE domain' sounds like rather sad reason to break the protocol. If there is something I don't understand, feel free to point it out - it is not a rare occurence :-)

Cheers,

-Markus

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 22 Mar 2007 08:01:21 -0400

> The question I would like to ask is this: with PANA (.. some day..) and 802.1x and whatever else out there, why are we reinventing the wheel badly on top of protocol that shouldn't do this part any…

802.1X does not work across Ethernet bridge.

Please see http://www.panasec.org/docs/PANA-FAQ.txt.

Yoshihiro Ohba

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Mar 2007 13:38:01 +0100

On Mar 22, 2007, at 12:17 PM, Markus Stenberg ((mstenber)) wrote:
> The question I would like to ask is this: with PANA (.. some day..)  
> and 802.1x and whatever else out there, why are we reinventing the  
> wheel badly on top of protocol that shouldn't do this part anyway?  
> 802.1x wasn't even mentioned in the DHC WG, despite being actually  
> currently most deployed (XP, Vista, MacOS X, about anything you  
> want to name it) link _authentication_ protocol. In my home  
> systems, I use ethernet all the way; why not replace PPPoE with  
> 802.1x in the general case?

The last time I had this conversation with somebody about 802.1x, the  
answer was "we can't make the customers buy all new switches that  
support 802.1x."   I realize that if you work at a company that sells  
smart switches, this could seem like a feature, not a bug, but for  
the end-user, replacing their network hardware with new hardware that  
supports 802.1x, particularly if they have a *lot* of network  
hardware, is not necessarily something that can be done in a single  
step.   Even if all that's required is a software update, if the  
update isn't free, and the per-unit cost isn't tiny, there's  
substantial pressure to find another way.   And even if upgrading the  
hardware were free, do we really want to force people to landfill  
working hardware if there is a reasonable solution that can be  
implemented in software?   We haven't agreed that there is a  
reasonable solution, but I don't think we've yet concluded that there  
isn't one, either.

---

From: "Markus Stenberg \(mstenber\)" <[email-masked]>
Date: Thu, 22 Mar 2007 20:39:59 +0800

>802.1X does not work across Ethernet bridge.

Yes.. I consider this feature and not a bug though (i.e. it actually authenticates directly connected node, and not node behind some arbitrary series of arbitrary links).

Is some ISP deployment scenario requiring use of bridges? Typically you'd want your home gateway / single computer authenticating with the whatever concentrator you have on the other side of the first-hop link.

Cheers,

-Markus