Alan DeKok wrote:
Richard Pruss wrote:
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".
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.
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".
Yes but the PANA stuff requires an IP address...
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.
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.
That seems a moral statement but so would your morals agree to run
authentication over BOOTP?
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.
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.
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.
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.
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)
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.
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.
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.
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
Alan DeKok.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
