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 On 4/17/07 4:09 AM, "Narayanan, Vidya" <[EMAIL PROTECTED]> 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. > > 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 > >> -----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
