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 > -----Original Message----- > From: Ralph Droms [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 17, 2007 2:27 PM > To: Narayanan, Vidya; Alan DeKok; Curtis Sherbo > Cc: [EMAIL PROTECTED] > Subject: Re: [Int-area] Discussion of subscriber authentication > > 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 _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
