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

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 13 Apr 2007 08:57:45 -0700 (PDT)

----- Original Message ----
From: Alan DeKok <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, April 10, 2007 2:59:26 PM
Subject: Re: [Int-area] Re: [dhcwg] Discussion of subscriber authentication

Behcet Sarikaya wrote:
> 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.

  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.

[behcet] agreed

  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.

[behcet]
Disagree. Without an IP address access to the Internet is restricted. Yes the host may have access to the link. 802.11 access points let you associate with open authentication but you can not use the network. It may be the same on DSL networks. 
The host can make a link-local address both in v4 and v6 but not a global address.

  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.

[behcet] Authentication failed, no IP address, what more can you do?

  Alan DeKok.

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

---

From: Ralph Droms <[email-masked]>
Date: Fri, 13 Apr 2007 12:06:11 -0400

Bechet - Your point "Without an IP address access to the Internet is
restricted. " is true; however, denying assignment of an address using DHCP
does not keep a host from getting a global IP address through some other
means like manual configuration, snooping the link to determine the
appropriate prefix and hijacking an address or (IPv6) address
autoconfiguration.

- Ralph

On 4/13/07 11:57 AM, "Behcet Sarikaya" <[email-masked]> wrote:

> Disagree. Without an IP address access to the Internet is restricted. Yes the
> host may have access to the link. 802.11 access points let you associate with
> open authentication but you can not use the network. It may be the same on DSL
> networks.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Apr 2007 18:17:49 +0200

Behcet Sarikaya wrote:
>  If someone avoids DHCP, and therefore
> Disagree. Without an IP address access to the Internet is restricted.

  DHCP is *advisory*.  The clients that do DHCP could just as well
configure a static IP, and get network access.

> [behcet] Authentication failed, no IP address, what more can you do?

  Sniff the local net.  Find an unused IP.  Configure it.

  Configuring static IP's is impossible only if the switch filters
traffic.  i.e. It blocks all network traffic except for DHCP, until the
DHCP IP has been allocated.  Once the IP has been allocated, it only
permits traffic that uses that source IP.

  This is not, as yet, a common configuration for a switch.

  Alan DeKok.

---

From: "Curtis Sherbo" <[email-masked]>
Date: Fri, 13 Apr 2007 10:47:34 -0700

I just want to clarify a few points that I think are being misunderstood.

1) Most modern broadband services that utilize DHCP instead of PPPoE do not
allow a subscriber to statically configure their IP address.  This is
prevented via the BRAS/NAS that is the subscribers default gateway, which
may be acting as a DHCP relay, proxy or server.  The BRAS will not install a
forwarding entry for a subscriber that it has not learned through the DHCP
process.  Forwarding entries are then built based on the assigned IP address
and the requesting MAC.  

2) I brought this up in Prague, but I will repeat it here.  Service
providers are using DHCP for authentication today.  They are just using it
in a primitive form.  They rely on the inserted Opt 82 information to
identify the subscriber to Radius.

3) Service providers typically do not want to allow configuration of a
client until they are authenticated.  Often because they will provide
alternate configuration depending on their identification.

4) The goal of draft-pruss-dhcp-auth-dsl is to provide an option for service
providers to maintain their investment in their current AAA infrastructures
with little or no changes to them.  I don't believe it is intended to alter
DHCP server implementations, but rather proxy/relays/servers that are
implemented in BRAS platforms.  I suppose this is really the area for
debate.

5) Client side implementations that would require modification are typically
in the control of the service provider.  They may be a managed residential
gateway, or a dsl modem.  User owned equipment is typically not allowed to
authenticate the PPPoE session today, I would see this as being no
different.

Regards,
Curtis Sherbo

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 9:18 AM
To: Behcet Sarikaya
Cc: [email-masked]
Subject: Re: [Int-area] Discussion of subscriber authentication

Behcet Sarikaya wrote:
>  If someone avoids DHCP, and therefore avoids this DHCP 
> "authentication", their ability to access the network is unrestricted.
> [behcet]

  DHCP is *advisory*.  The clients that do DHCP could just as well configure
a static IP, and get network access.

  Configuring static IP's is impossible only if the switch filters traffic.
i.e. It blocks all network traffic except for DHCP, until the DHCP IP has
been allocated.  Once the IP has been allocated, it only permits traffic
that uses that source IP.

  Alan DeKok.

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 13 Apr 2007 23:07:55 +0300

> identify the subscriber to Radius.

That's not really "authentication". It is simply "identification" by means
of "piggybacking an identifier on the 'DHCP relay protocol' ". This is
totally different from the scheme proposed by draft-pruss.

> with little or no changes to them.  

I don't understand how the draft-pruss relates to "maintaining AAA
infrastructure". What AAA infra is maintained by means of using draft-pruss,
and what infra may need to change if something else is used?

> I don't believe it is intended to
> alter

DHCP terminates on a DHCP server, hence the draft-pruss requires
modifications on the server.

> gateway, or a dsl modem.  

Is there an assumption that draft-pruss works with "service provider managed
residential gateways"? Why is that so?

Alper

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Apr 2007 03:08:22 +0200

Curtis Sherbo wrote:
> ...  The BRAS will not install a

  Ah. That wasn't clear from the draft.

> alternate configuration depending on their identification.

  That's fine.  Can they use EAP?

> implemented in BRAS platforms.  I suppose this is really the area for

  The draft could be implemented by having the relay filter & edit DHCP
requests.  That's awkward, though, and possible only because the DHCP
packets are unsigned....

> authenticate the PPPoE session today, I would see this as being no

  An alternate solution that would achieve the same goal, but wouldn't
require piggy-backing authentication onto DHCP would be to use EAP.
EAP-MD5 is already supported by all supplicants, and is just CHAP.
Using EAP also permits the authentication methods to be updated without
modifying DHCP.

  The only problem is that wired authentication does not have the
equivalent of wireless systems broadcasting SSID's.  That problem can be
addressed via the following method.

  1) Client sends a DHCP DISCOVER or DHCP request
  2) relay (BRAS) responds with "DHCP AUTH required"
     This would be a new DHCP message, containing a list of
     authentication domains (read: SSIDs).
  3) Client does EAP to BRAS
  4) on EAP success, client performs DHCP again.

  The downside to this approach is that it requires more code on the
client and on the BRAS than just putting CHAP into DHCP.  The upside is
that I think it may get wider acceptance than CHAP inside of DHCP.  It
leaves authentication to EAP, and network configuration to DHCP.

  i.e. one of the widely acknowledged problems in performing EAP
authentication for wired networks is the inability to know that EAP is
a requirement.  A related problem is that even if the client knows EAP
is required, it doesn't know which network it is connected to, and
therefore which credentials it should present.

  With this approach, it's clear that the BRAS is blocking all DHCP
traffic, and not rewriting packets.  It's also clear that DHCP servers
do not have to change.  DHCP clients have to change, but hopefully
minimally, and only to kick-start an EAP session when a DHCP "Auth
required" packet is received.  The existing client DHCP timers for
retransmits, etc. could even be left alone, as the EAP session *should*
finish before the next DHCP request is sent.

  If this appears to be a viable approach, I can write up a draft this
coming week.

  Alan DeKok.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 17 Apr 2007 01:09:13 -0700

Having read the messages in this thread and having skimmed
draft-pruss-dhcp-auth-dsl, I think we are talking about a case of
authentication here required to ensure that only authenticated and
authorized clients obtain the config information. DHCP message
authentication doesn't quite seem to be a goal. Please correct me if I'm
wrong here. 

On whether we should be defining a means of carrying EAP in DHCP, I
would vote no. EAP is designed to work in cases where the clients may
greedily attempt network access, while the network requires
authentication. So, the case where the client attemtps DHCP and the
network sends an EAP Request/Identity to trigger EAP is very much a
common model. EAPoL (802.1x) is already a defined encapsulation for EAP
and is meant to occur before any IP-level configuration is obtained. 

On using EAP-MD5, I understand the need to re-use available credentials.
However, it is important to note that such authentication doesn't
provide any key material and hence, subsequent exchanges can't be
secured based on that. This means that there is no means of correlating
the DHCP exchange with an entity that authenticated successfully - so, a
different entity that manages to spoof the MAC address of the
authenticated entity can get away with obtaining the same information.
I'm not sure how much of a concern that is in the DSL environment, but,
if ethernet is to be the L2, that seems feasible to me. I am guessing
that we are perhaps relying on some kind of mapping between an actual
wire and the authenticated entity here? 

In general, we need to look at the requirements more closely before we
define using DHCP as another lower layer for EAP. At least from what I
see so far here, it doesn't seem required. And, keeping with the more
general view of using EAP as a tool for network access prior to
exchanging any other data, including DHCP or perhaps NDP in the v6
world, seems like a good idea. 

Regards,
Vidya

> Sent: Friday, April 13, 2007 6:08 PM
> To: Curtis Sherbo
> Cc: [email-masked]
> > forwarding entry for a subscriber that it has not learned 
> through the 
> > DHCP process.  Forwarding entries are then built based on 
> the assigned 
> > IP address and the requesting MAC.
> 
> > 4) The goal of draft-pruss-dhcp-auth-dsl is to provide an 
> option for 
> > service providers to maintain their investment in their current AAA 
> > infrastructures with little or no changes to them.  I don't 
> believe it 
> > is intended to alter DHCP server implementations, but rather 
> > proxy/relays/servers that are implemented in BRAS platforms.  I 
> > suppose this is really the area for debate.
> 
>   The draft could be implemented by having the relay filter & 
> edit DHCP requests.  That's awkward, though, and possible 
> only because the DHCP packets are unsigned....
> 
> > 5) Client side implementations that would require modification are 
> > typically in the control of the service provider.  They may be a 
> > managed residential gateway, or a dsl modem.  User owned 
> equipment is 
> > typically not allowed to authenticate the PPPoE session 
> today, I would 
> > see this as being no different.
> 
>   An alternate solution that would achieve the same goal, but 
> wouldn't require piggy-backing authentication onto DHCP would 
> be to use EAP.
> Using EAP also permits the authentication methods to be 
> updated without modifying DHCP.
> 
>   The only problem is that wired authentication does not have 
> the equivalent of wireless systems broadcasting SSID's.  That 
> problem can be addressed via the following method.
> 
>   The downside to this approach is that it requires more code 
> on the client and on the BRAS than just putting CHAP into 
> DHCP.  The upside is that I think it may get wider acceptance 
> than CHAP inside of DHCP.  It leaves authentication to EAP, 
> and network configuration to DHCP.
> 
>   i.e. one of the widely acknowledged problems in performing 
> EAP authentication for wired networks is the inability to 
> know that EAP is a requirement.  A related problem is that 
> even if the client knows EAP is required, it doesn't know 
> which network it is connected to, and therefore which 
> credentials it should present.
> 
>   With this approach, it's clear that the BRAS is blocking 
> all DHCP traffic, and not rewriting packets.  It's also clear 
> that DHCP servers do not have to change.  DHCP clients have 
> to change, but hopefully minimally, and only to kick-start an 
> EAP session when a DHCP "Auth required" packet is received.  
> The existing client DHCP timers for retransmits, etc. could 
> even be left alone, as the EAP session *should* finish before 
> the next DHCP request is sent.
> 
>   If this appears to be a viable approach, I can write up a 
> draft this coming week.
> 
>   Alan DeKok.
>

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Apr 2007 07:26:47 -0400

Vidya - we're hoping to get a list of requirements from the DSL Forum, which
we can use as the basis for analyzing how to provide subscriber
authentication.

- Ralph

---

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

> authentication doesn't quite seem to be a goal. Please correct me if I'm
Correct.
> greedily attempt network access, while the network requires
IPv4 addresses are certainly are a limited resource that warrant 
protection from greedy denial of service exhaustion attacks. Current 
protections in SP networks are implemented on the first hop switch and 
limit the number of addresses per line,  DHCP authentication would be a 
simpler and stronger model.
>  So, the case where the client attemtps DHCP and the
EAPoL does not traverse the layer 2 network.  EAPoL works to the first 
layer 2 hop and is has many well understood limitations in terms of 
these deployments.

> wire and the authenticated entity here?
It is a concern and the mapping between actual wire and authenticated 
entity is made by the DSLAM  or first L2 switch in metro.
> world, seems like a good idea.
The second alternative in the draft is about getting EAP prior to 
exchanging data, the difference from a stand alone mechanism is that we 
are aiming for fate sharing as we want the authentication to inform the 
configuration retrieval from AAA.

-Ric

>>> 3) Service providers typically do not want to allow 
>>>       
>> configuration of a 
>>     
>>> client until they are authenticated.  Often because they 
>>>       
>> will provide 
>>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 19 Apr 2007 15:43:26 +0300

There is the dsl2006.174.02.doc contribution that lists a set of
requirements for subscriber authentication.

Sorry, I am not sure about the DSLF policy, so I cannot forward the
document.
But this is a Cisco contribution. Maybe someone from Cisco can share it with
us.

Alper

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2007 2:27 PM
> To: Narayanan, Vidya; Alan DeKok; Curtis Sherbo
> Cc: [email-masked]