Subject: RE: [Int-area] Re: [dhcwg] Discussion of subscriber authentication

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Apr 2007 11:14:19 -0500

Hi Hesham,
 Have you read draft-pruss? If you look at Figure 1, it is not replacing 
AAA servers with DHCP servers, DHCP server acts like NAS. I agree that 
DHCP has been overloaded and I think it is this issue that Ralph wants 
discussed.

Regards,

Behcet
> The authentication in RFC 3118 (for DHCPv4) and RFC 3315 
 > (for DHCPv6)  > is message authentication, not subscriber 
authentication.
 > > Message authentication is all about ensuring that the contents are  
 > not fake, assuming that there is enough shared trust between client  
 > and server host computers.  The shared trust also serves to control  
 > authorization to exchange DHCP messages.
 > > Subscriber authentication is about the user of network access, and  
 > the user is often the person who has credentials rather than the  > 
host, although storing user credentials on the host happens.
 > > The point of section 2.5 of draft-aboba-ip-config-00.txt is that  > 
these are different:
 > >    2.5.  Configuration is Not Access Control
 > >     Network access authentication is a distinct problem from Internet
 >     host configuration.
 >
=> I couldn't agree more. I don't see the need for replacing AAA servers
with DHCP servers or overloading DHCP for this purpose.
Hesham

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 10 Apr 2007 21:59:26 +0200

> DHCP has been overloaded and I think it is this issue that Ralph wants

  The DHCP server receives an unsigned, unencrypted packet from some
random device on the net, that could very well be spoofed... and uses
that to initiate a signed, potentially encrypted authentication session
with a AAA server.

  I don't think that's a very good idea.

  At least with normal AAA access requests there's an underlying session
that the NAS can hang up on.  e.g. Dial-up session, PPPoE, TCP
connection, etc.  The NAS may have no idea who the caller is, but it can
forcibly boot them off of the network if authentication fails.  DHCP
servers have no such power.  If someone avoids DHCP, and therefore
avoids this DHCP "authentication", their ability to access the network
is unrestricted.

  This proposal complicates the network for limited benefit, and can
easily be worked around.  It depends on untrusted clients doing the
"right thing" when they're told authentication has failed, which is an
interesting approach to network security.

  Alan DeKok.

---

From: Richard Pruss <[email-masked]>
Date: Tue, 17 Apr 2007 19:08:11 +1000

> that to initiate a signed, potentially encrypted authentication session
I think you have misunderstood the draft, possibly I was not clear 
enough, two points of clarification for you concerns:
1. In the draft the DHCP server is the NAS and it has layer 2 restricted 
relationship with the device offering credentials.  There is no 
technical difference between where this is running and where and PPPoE 
is used, the only difference is that after authentication, services like 
multicast can be introduced from Layer 2 devices before the NAS, which 
is why providers want to move from PPPoE.
2. In the second option in the draft one may run EAP over DHCP which can 
be as encrypted and signed to your hearts content.

-Ric

---

From: Alan DeKok <[email-masked]>
Date: Tue, 17 Apr 2007 11:40:35 +0200

> is why providers want to move from PPPoE.

  I do agree that DHCP has to be part of the solution to this problem.
Most clients will do DHCP before anything else, so putting some kind of
tie in to authentication requirements in DHCP is very useful.

  But does DHCP have to carry the authentication itself, or just the
notification that authentication is required?  i.e. Can't the DHCP
server just say "you must do PANA/EAPoL before I give you a lease".

> be as encrypted and signed to your hearts content.

  i.e. Yet another transport layer for EAP.  We already have PPP, EAPoL,
PANA, RADIUS, Diameter, etc. to carry EAP.  I'm wary of adding one more.

  And my issue isn't the signing and encrypting part.  It's that we
already have solutions to these problems.  The protocols exist, and in
some cases, are deployed on tens of millions of clients.  Rather than
updating the DHCP stack to do EAP, it would seem to be much easier to
have the DHCP stack *inform* the rest of the system that authentication
was required.  The system could then do PPPoE, PANA, EAPoL, or whatever
else was appropriate for the link.

  Alan DeKok.

---

From: Richard Pruss <[email-masked]>
Date: Wed, 18 Apr 2007 09:03:41 +1000

> server just say "you must do PANA/EAPoL before I give you a lease".

When we work through the details of the system for authenticate later 
with PANA/EAPoL or Web Authentication, some problems arise here are some:
1. @Domain in the authentication is typically used by wholesale DSL 
providers to choose which ISP and thus IP address domain you are in.  If 
you get that information after the IP address needs to be allocated, you 
need to do some two step hack to re-address the client after authentication.
2. DHCP auth is far more about getting configuration information from 
very large existing AAA databases (currently used for PPPoE and the SP 
operations processes around those) and correctly configuring the Host 
and the NAS with that information than "Authentication".  Authenticating 
later does not solve the real problem of getting the client information 
from the AAA databases without changing the AAA and operational 
infrastructure supporting millions of live users.
3. The current proposal  requires a change to the Home Gateway and NAS 
but as it uses functions in the system that assume DHCP other solutions 
would be needed for:
3.1 Line ID - currently the DSLAM or first hop L2 switch (in MetroE) 
marks the residential line into Option 82 in DHCP (or PPP tag in PPPoE) 
this is used to support the credentials in authentication (Something you 
are, Something you know, etc.)  or at least inform the choice of 
configuration.  This would mean that we would need some new mechanism to 
snoop PANA and insert Line ID. When I evaluated this PANA could not be 
snooped but Alper tells me this has changed.
3.2 Source Address Verification, ARP protection, Layer 2 VLAN security 
policies -  Most  vendors now snoop the DHCP as the major mechanism 
informing the layer 2 protections against a host of bad behaviours.  As 
we move content that was behind the NAS to in front of the NAS these 
protections are even more important not just for Layer 2 but also for 
any Layer 3 content devices like VOD pumps etc.  With the DHCP auth 
proposal the DHCP transaction continues in this function but with the 
PANA/EAPol approach we would need a policy distribution mechanism to 
contact the L2 edge and change the policies post authentication.
3.3 Introducing changes to the DSLAMs and L2 switches is far more 
expensive for the SP to migrate to and the vendors to impliment.

> PANA, RADIUS, Diameter, etc. to carry EAP.  I'm wary of adding one more.
That is a tribute to EAP and something the community should be happy 
about  as the alternative was that all those were doing there own 
Authentication Protocols.

-Ric

---

From: Alan DeKok <[email-masked]>
Date: Wed, 18 Apr 2007 09:34:06 +0200

> need to do some two step hack to re-address the client after authentication.

  Yes, it's a problem.  Can't the DHCP relay just respond to the
DISCOVER with a response "Authentication required"?  It doesn't have to
assign a lease.  As you pointed out, it *can't* assign a lease until
after authentication has succeeded.

  The "DHCP authentication required" response could be a DHCP OFFER
packet, with some new options.  The endpoint would interpret those
options as requesting authentication.  The switch would interpret the
DHCP offer as it does today: "the lease is not yet assigned, do not
forward IP traffic".

> infrastructure supporting millions of live users.

  I see it is valuable to tie DHCP parameters to a particular
authentication session.  This is a known problem in 802.1x wired
authentication today, where the end device does not know that 802.1x is
required, and does not know which authentication domain to use.

  It would be wonderful to use DHCP to carry the information that
authentication is required.  It would be wonderful to use DHCP to carry
information about the authentication domain.  It would be very bad to
use DHCP as a transport protocol for authentication.

> snooped but Alper tells me this has changed.

  This kind of thing is done already for EAPoL (or 802.1x).  The switch
collects the EAPoL traffic from the EAP client, packages it into a
RADIUS request, and adds a set of auxiliary information like port, line
ID, port MAC address, etc.

  This solution is available in most switches, and is widely deployed.
It also means that the policy enforcement point is the L2 switch, which
prevents a number of local network attacks from unauthenticated endpoints.

> contact the L2 edge and change the policies post authentication.

  If the L2 edge is acting as an authentication proxy, it can be
informed of the policies when authentication succeeds.  These include
VLAN information, etc.  Those policies can be much more complex than
what can be inferred by snooping DHCP.  The policies are also explicit,
whereas with DHCP they are implicit. (e.g. assignment of IP means
allowing only that IP)

> expensive for the SP to migrate to and the vendors to impliment.

  If the deployed DSLAMs and L2 switches already support 802.1x, then
the proposal outlined here would likely not require changes to the
switches.  It would require small changes to a DHCP server, and small
changes to the DHCP clients.

  If, however, the equipment does not support 802.1x, then the solution
becomes more complicated.  I'm concerned, though, about *not* using an
existing solution simply because it has deployment costs.  Adding EAP to
DHCP also has deployment costs, and is yet another overlapping solution
to the network access problem.

  Alan DeKok.

---

From: Richard Pruss <[email-masked]>
Date: Thu, 19 Apr 2007 14:46:59 +1000

> DHCP offer as it does today: "the lease is not yet assigned, do not
Yes but the PANA stuff requires an IP address...
> use DHCP as a transport protocol for authentication.
That seems a moral statement but so would your morals agree to run 
authentication over BOOTP?

> prevents a number of local network attacks from unauthenticated endpoints.
Yes but EAPoL gives you port security and not per subscriber identity 
and fails on very basic requirements like multiple identities on a 
single port for Video vs Data.  Of course there are also all the 
operational problems of then getting your L3 boundary in sync with your 
now L2 authentication point and of course the many cases where the L2 
edge is not physically secure like multi-tenant buildings where you 
could simply remove the config from the device and then you are on the 
network.

> whereas with DHCP they are implicit. (e.g. assignment of IP means
Current Enterprise and SP networks treat DHCP as explicit and do not 
allow addresses that are not DHCP assigned into the ARP table or to be 
forwarded.  All switch and router vendors have a multitude of features 
on this topic.
> to the network access problem.
I would have loved to use 802.1x from the client to the NAS as it would 
be much easier all around but 802.1x does not traverse a bridge and it 
does not support multiple identities on a single port without really 
horrible security gaps.

-Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 19 Apr 2007 16:57:02 +0300

Hi Ric,

When we work through the details of the system for authenticate later with
PANA/EAPoL or Web Authentication, some problems arise here are some:

1. @Domain in the authentication is typically used by wholesale DSL
providers to choose which ISP and thus IP address domain you are in.  If you
get that information after the IP address needs to be allocated, you need to
do some two step hack to re-address the client after authentication.

Alper> This is not a hack and it is already available and used. If we go
with IPv4 or IPv6 link-local address configuration before PANA
authentication, changing from IPv4 link-local to non-link-local, or adding
global IPv6 to link-local IPv6 is what we need and is already done on host
stacks.

2. DHCP auth is far more about getting configuration information from very
large existing AAA databases (currently used for PPPoE and the SP operations
processes around those) and correctly configuring the Host and the NAS with
that information than "Authentication".  Authenticating later does not solve
the real problem of getting the client information from the AAA databases
without changing the AAA and operational infrastructure supporting millions
of live users.

Alper> Performing PANA before configuring host via DHCP enables what you are
seeking. 

3. The current proposal  requires a change to the Home Gateway and NAS but
as it uses functions in the system that assume DHCP other solutions would be
needed for:
3.1 Line ID - currently the DSLAM or first hop L2 switch (in MetroE) marks
the residential line into Option 82 in DHCP (or PPP tag in PPPoE) this is
used to support the credentials in authentication (Something you are,
Something you know, etc.)  or at least inform the choice of configuration. 
This would mean that we would need some new mechanism to snoop PANA and
insert Line ID. When I evaluated this PANA could not be snooped but Alper
tells me this has changed.

Alper> I understand how line identifier is used in the current systems, due
to lack of any crypto-based authentication. I'm wondering if we still need
that even if we are authenticating the subscribers via EAP? 

3.2 Source Address Verification, ARP protection, Layer 2 VLAN security
policies -  Most  vendors now snoop the DHCP as the major mechanism
informing the layer 2 protections against a host of bad behaviours.  As we
move content that was behind the NAS to in front of the NAS these
protections are even more important not just for Layer 2 but also for any
Layer 3 content devices like VOD pumps etc.  With the DHCP auth proposal the
DHCP transaction continues in this function but with the PANA/EAPol approach
we would need a policy distribution mechanism to contact the L2 edge and
change the policies post authentication.

Alper> As I understood earlier, L2 edge that performs per-packet access
control relies on snooping DHCP messages to learn who is "authorized" to
access the network. This is an implicit method. Based on this
understanding...

Alper> Since we'd be using DHCP after PANA, the L2 edges can keep relying on
the same mechanism. 

Regards,

Alper

---

From: Alan DeKok <[email-masked]>
Date: Thu, 19 Apr 2007 10:02:39 +0200

Richard Pruss wrote:
...
> Yes but the PANA stuff requires an IP address...

  OK.  Part of the confusion, I think, is the draft presents a solution
without discussing the problem space in detail.  i.e. There are already
multiple kinds of network access protocols, as we have been discussing
here.  Yet the draft doesn't say why those other protocols do not apply
to this situation.  Instead, it just proposes a solution.

  It would have shortened this discussion if the draft had had 3-4
paragraphs about the network topology, and why PANA, 802.1x, etc. won't
work.

>> ...  It would be very bad to

  It's a statement from experience and best practices.  Maybe "bad" is a
morally loaded word.  Perhaps "inefficient", or "awkward", or
"re-inventing the wheel" would be more acceptable.

...
> could simply remove the config from the device and then you are on the

  If the L2 edge isn't secure, then the solution becomes much simpler.
Always give the subscriber an IP address, because they can probably
sniff the net and pick a local unused IP anyways.  Then, at the L3
boundary, perform firewalling and filtering until the individual users
are authenticated.

  This is done today in the wireless arena, in captive portals.  It
gives subscriber identity.  It ties subscriber identity to IP address,
and usually to MAC address, too.  It provides for multiple identities on
a single port.  It provides for dynamic download (and update) of
firewall filtering && QoS rules to the L3 device.

> forwarded.  All switch and router vendors have a multitude of features

  Many products implement features that go beyond the original goals of
the protocol.

> does not support multiple identities on a single port without really

  Are there reasons why a captive portal wouldn't work?

  Alan DeKok.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Apr 2007 09:32:26 -0400

In between a description of "the network topology", and "why PANA, 802.1x,
etc. won't work.", we need a list of requirements.

- Ralph

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Mon, 23 Apr 2007 00:27:28 +0300

Hello, 

In addition to the requirements list, it would be good to know if the needed
thing is specific for DSL or should it be more generic.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Apr 2007 18:47:13 -0400

Good point; I agree...

- Ralph

---

From: Richard Pruss <[email-masked]>
Date: Thu, 26 Apr 2007 09:00:05 +1000

I certainly was hoping that this would cover the DSL and metro edges.  
These are SP environments we often see deployed together in our customers.

-Ric

---

From: Richard Pruss <[email-masked]>
Date: Thu, 26 Apr 2007 09:05:41 +1000

There is a "living list" of requirements that apply from the IP session 
work in the DSLForum.  We will try corral some interested parties in 
putting a contribution in for the Beijing DSForum meeting asking that 
the DSLForum publish the requirements list to the IETF for this discussion.

-Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 27 Apr 2007 01:13:12 +0300

We had done an analysis of PANA and IEEE 802.1X based on those requirements
earlier. Please see the attached document.

Neither in the light of those requirements, nor in IETF discussions I can
see why PANA is not sufficient for this problem. Can someone explain?

Alper

 

  _____  

From: Richard Pruss [mailto:[email-masked]] 
Sent: Thursday, April 26, 2007 2:06 AM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [Int-area] Re: [dhcwg] Discussion of subscriber authentication

There is a "living list" of requirements that apply from the IP session work
in the DSLForum.  We will try corral some interested parties in putting a
contribution in for the Beijing DSForum meeting asking that the DSLForum
publish the requirements list to the IETF for this discussion.

-Ric

Ralph Droms wrote: 

- Ralph
 
On 4/19/07 4:02 AM, "Alan DeKok"  <mailto:[email-masked]>
<[email-masked]> wrote:

Richard Pruss wrote:
...

 
  It would have shortened tFrom [email-masked] Mon Apr 30 19:20:20 2007
From: "Alper Yegin" <[email-masked]>
To: <[email-masked]>,
	"'Ralph Droms'" <[email-masked]>
Subject: RE: [Int-area] Re: [dhcwg] Discussion of subscriber authentication
Date: Fri, 27 Apr 2007 01:13:12 +0300
Cc: [email-masked]

This is a multi-part message in MIME format.

We had done an analysis of PANA and IEEE 802.1X based on those requirements
earlier. Please see the attached document.

Neither in the light of those requirements, nor in IETF discussions I can
see why PANA is not sufficient for this problem. Can someone explain?

Alper

 

  _____  

From: Richard Pruss [mailto:[email-masked]] 
Sent: Thursday, April 26, 2007 2:06 AM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [Int-area] Re: [dhcwg] Discussion of subscriber authentication

There is a "living list" of requirements that apply from the IP session work
in the DSLForum.  We will try corral some interested parties in putting a
contribution in for the Beijing DSForum meeting asking that the DSLForum
publish the requirements list to the IETF for this discussion.

-Ric

Ralph Droms wrote: 

- Ralph
 
On 4/19/07 4:02 AM, "Alan DeKok"  <mailto:[email-masked]>
<[email-masked]> wrote:

Richard Pruss wrote:
...

 

 
...

 

 
  Alan DeKok.