Narayanan, Vidya wrote:
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.
Correct.
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.
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
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.
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.
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?
It is a concern and the mapping between actual wire and authenticated
entity is made by the DSLAM or first L2 switch in metro.
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.
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
Regards,
Vidya
-----Original Message-----
From: Alan DeKok [mailto:[EMAIL PROTECTED]
Sent: Friday, April 13, 2007 6:08 PM
To: Curtis Sherbo
Cc: [EMAIL PROTECTED]
Subject: Re: [Int-area] Discussion of subscriber authentication
Curtis Sherbo wrote:
... 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.
Ah. That wasn't clear from the draft.
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.
That's fine. Can they use EAP?
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.
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.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
