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
