Subject: [dhcwg] http://www.ietf.org/internet-drafts/draft-vinokour-dhcp-reconfigure-option-00.txt

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 7 Jun 2008 10:17:09 -0400

Hi:
 
As unauthenticated DHCPFORCERENEW messages may cause concern in the
IESG, why not define the DHCPv6 Reconfigure Key Authentication Protocol
for use with RFC 3118.
 
This should be very straightforward and it provides the same level of
protection already in place for DHCPv6.
 
There is one subtle difference though with respect to DHCPv6 and DHCPv4
here that is important. In DHCPv6, the reply to the client is always
unicast. In DHCPv4, it may be broadcast. This must be pointed out in the
security considerations (though in reality this is hopefully no longer
used by most clients and a rogue device could always enable promiscuous
mode and therefore capture unicast traffic).
 
- Bernie
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Vitali Vinokour (vvinokou)" <[email-masked]>
Date: Sat, 7 Jun 2008 17:57:23 -0400

Bernie,
 
Security provided by Reconfigure Key Authentication Protocol is rather
weak because the key is provided in-band and can be intercepted by a
malicious user. It seems rather odd to define a brand-new authentication
mechanism for DHCPv4 that is not really secure just to be on a par with
DHCPv6. 
 
The use of unathenticated DHCPFORCERENEW is only recommended for
networks where security can be provided by other means, as is the case
in TR-101 access networks where subscriber isolation is enforced via 1:1
VLANs or DHCP snooping on DSLAMs. 
 
Thanks,
Vitali

________________________________

	From: Bernie Volz (volz) 
	Sent: Saturday, June 07, 2008 10:17 AM
	To: DHC WG; Vitali Vinokour (vvinokou); Wojciech Dec (wdec);
[email-masked]; [email-masked]
	Subject:
http://www.ietf.org/internet-drafts/draft-vinokour-dhcp-reconfigure-opti
on-00.txt

	Hi:
	 
	As unauthenticated DHCPFORCERENEW messages may cause concern in
the IESG, why not define the DHCPv6 Reconfigure Key Authentication
Protocol for use with RFC 3118.
	 
	This should be very straightforward and it provides the same
level of protection already in place for DHCPv6.
	 
	There is one subtle difference though with respect to DHCPv6 and
DHCPv4 here that is important. In DHCPv6, the reply to the client is
always unicast. In DHCPv4, it may be broadcast. This must be pointed out
in the security considerations (though in reality this is hopefully no
longer used by most clients and a rogue device could always enable
promiscuous mode and therefore capture unicast traffic).
	 
	- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 7 Jun 2008 19:46:11 -0400

Well, in that environment the key could not be intercepted :).
 
While RKAP is not strong security it does improve the situation as a
malicious device needs to have the ability to monitor multiple messages,
which may be very infrequent (depending on the lease times/connection
rates). And what harm is there in providing some added security?
 
And if this is built into the DHCP client of devices (PCs) that could be
mobile and connect via various networking technologies, how would that
device know when it could/should do this?
 
Again, I think you'll have a difficult time getting this by the IESG
without something more than "only implement this in networks where
security can be provided by other means".
 
- Bernie

From: Vitali Vinokour (vvinokou) 
Sent: Saturday, June 07, 2008 5:57 PM
To: Bernie Volz (volz); 'DHC WG'; Wojciech Dec (wdec);
[email-masked]'; [email-masked]'
Subject: RE:
http://www.ietf.org/internet-drafts/draft-vinokour-dhcp-reconfigure-opti
on-00.txt

Bernie,

 
Thanks,
Vitali

	From: Bernie Volz (volz) 

	Hi:

	 
	 
	- Bernie

---

From: John Jason Brzozowski <[email-masked]>
Date: Wed, 11 Jun 2008 00:40:04 -0400

I have to agree with the original message in that the absence of some sort
of authentication seems unwise.

The opportunity for a malicious user to intercept DHCPv6 messages where
Reconfigure keys are present depends in part of the deployment, no?

Is there a specific concern around leaving in place the authentication that
is already specified?  Can you elaborate?  Apologies if this has been
discussed elsewhere.

John

On 6/7/08 7:46 PM, "Bernie Volz (volz)" <[email-masked]> wrote:

> While RKAP is not strong security it does improve the situation as a malicious
> device needs to have the ability to monitor multiple messages, which may be
> very infrequent (depending on the lease times/connection rates). And what harm
> is there in providing some added security?
>  
> mobile and connect via various networking technologies, how would that device
> know when it could/should do this?
>  
> Again, I think you'll have a difficult time getting this by the IESG without
> something more than "only implement this in networks where security can be
> provided by other means".
>  
> - Bernie
> 
> 
> http://www.ietf.org/internet-drafts/draft-vinokour-dhcp-reconfigure-option-00.
> txt
> 
> Bernie,
>  
> Security provided by Reconfigure Key Authentication Protocol is rather weak
> because the key is provided in-band and can be intercepted by a malicious
> user. It seems rather odd to define a brand-new authentication mechanism for
> DHCPv4 that is not really secure just to be on a par with DHCPv6.
>  
> The use of unathenticated DHCPFORCERENEW is only recommended for networks
> where security can be provided by other means, as is the case in TR-101 access
> networks where subscriber isolation is enforced via 1:1 VLANs or DHCP snooping
> on DSLAMs. 
>  
> Thanks,
> Vitali
> 
>>  
>>  
>> 
>>  From: Bernie Volz (volz)
http://www.ietf.org/internet-drafts/draft-vinokour-dhcp-reconfigure-option-00>>
.
>> txt
>> 
>>  
>>  
>> Hi:
>>  
>>  
>>  
>> As unauthenticated  DHCPFORCERENEW messages may cause concern in the IESG,
>> why 
>> not define the  DHCPv6 Reconfigure Key Authentication Protocol for use with
>> RFC  3118.
>>  
>>  
>>  
>> There is one  subtle difference though with respect to DHCPv6 and DHCPv4 here
>> that is  important. In DHCPv6, the reply to the client is always unicast. In
>> DHCPv4, it  may be broadcast. This must be pointed out in the security
>> considerations  (though in reality this is hopefully no longer used by most
>> clients and a  rogue device could always enable promiscuous mode and
>> therefore 
>> capture  unicast traffic).
>>  
>>  
>>  
>> -  Bernie

=========================================
John Jason Brzozowski
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
=========================================