Subject: Re: [Int-area] Discussion of subscriber authentication

From: Richard Pruss <[email-masked]>
Date: Tue, 08 May 2007 18:36:42 +1000

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-masked]> 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-masked]]
>>> Sent: Friday, April 13, 2007 6:08 PM
>>> To: Curtis Sherbo
>>> Cc: [email-masked]
>>> 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-masked]
>>> https://www1.ietf.org/mailman/listinfo/int-area
>>>
>>>       
>> _______________________________________________
>> Int-area mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/int-area
>>     
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area
>
>   
_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Ralph Droms <[email-masked]>
Date: Tue, 08 May 2007 16:43:57 -0400

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