Ric - I think Mark would be able to initiate the liaison discussion better than I, as he is a member of the IESG and has some experience with the DSLForum.
- Ralph On 5/8/07 4:35 AM, "Richard Pruss" <[EMAIL PROTECTED]> wrote: > Hi Ralph, > > I am not sure how these liason things work but is it possible to > generate some sort of liason statement from the IETF requesting the v2.4 > of WT-146 which has the requirements for IP sessions and has changes > agreed up to Vancouver meeting of the DSLForum. > > Thanks, > Ric >> 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
