Subject: [dhcwg] Accepting the following drafts as WG work items

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 18 Sep 2008 01:15:44 -0400

At the last dhc WG meeting, the consensus of attendees at the meeting
was to accept the following drafts as WG work items:

draft-miles-dhc-dhcpv6-ldra-00
draft-kurapati-dhc-leasequery-by-remote-id-01

If you feel that one or both of these drafts should not be accepted as
WG work items, please respond to the WG mailing list by Mon, 09-26-2008.

-Ralph Droms, John Brzozowski
   dhc WG chairs

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 18 Sep 2008 01:26:20 -0400

At the last dhc WG meeting, the consensus of attendees at the meeting
was to accept the following draft as a WG work item:

draft-vinokour-dhcp-reconfigure-option-00

However, prior to doing so we agreed that some additional discussions is
required.  Specifically, we are requesting that the dhc WG consider whether
disabling or turning off security is acceptable or if a nonce method (as
specified as part of DHCPv6) should be required?

If you feel that this is inaccurate please reply to the list.  Further, if
you feel that this draft should not be accepted as a WG work items, please
respond to the WG mailing list by Mon, 10-01-2008.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Sep 2008 22:35:54 -0700

> specified as part of DHCPv6) should be required?

I was one of the people (perhaps the only one - I don't remember!) who  
wanted to know why we couldn't use a nonce.   My recollection is that  
the authors agreed to look into the nonce security model as defined in  
RFC3315.

My position on this was that a draft adapting the nonce model for use  
with DHCPv4 would be worth considering.   However, this draft contains  
no security precautions at all, meaning that it would be trivial for  
an attacker to trigger a renew on a client that implemented it.   So  
I'd be against adopting this draft as it stands as a WG item.

---

From: "MILES DAVID" <[email-masked]>
Date: Tue, 23 Sep 2008 05:26:23 +0800

Ted,

>However, this draft contains  

The intention was to use this in networks using Broadband Forum TR-101
architectures or similar (per the introduction). These networks are
usually configured to prevent forwarding of traffic between user ports.
I think this would mitigate the attack vector you suggest. An attacker
would need to be in-line (between DHCP client and access node) to issue
this renew and if a MITM approach was exploited the use of a nonce would
be similarly vulnerable.

Right now there are deployed routed gateways and DHCP servers that are
violating the current RFC3203 by not implementing DHCP-AUTH. The hope
was to do something very minor (adding a new DHCP option) to these
gateways vs. implementing a HMAC/MD5 function that would be needed for a
nonce/Reconfigure Key. This argument may be quite weak, but it is what
motivated the creation of this draft.  It would seem that either
restricted forwarding topology or Reconfigure Key would provide
comparable security, so we preferred the easier option. That said, would
you be willing to alter your view if a requirement was explicitly stated
described a restricted L2 topology?

Cheers,

David

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Sep 2008 14:45:10 -0700

> this renew and if a MITM approach was exploited the use of a nonce  

Right, that was mentioned in the meeting in Dublin.   However, my  
rejoinder, which was not countered, is that we can't assume this  
protocol will be used only in TR-101 environments, and therefore the  
minimal level of spoof-prevention offered by the nonce security  
protocol is worth implementing.   And since it's not hard to  
implement, it shouldn't be seen as an impediment to implementation.

I should say that I didn't use the correct name for the authentication  
protocol I was recommending either in Dublin or in my most recent  
message on this subject.   The protocol I'm talking about is the  
Reconfigure Key Authentication Protocol as described in RFC3315  
section 21.5.

> described a restricted L2 topology?

I think requirements like that are a bit toothless.   If the  
reconfigure key protocol were hard to implement, I might have more  
sympathy.   But it's not, so I don't.   HMAC/MD5 is trivial to  
implement - you really don't have to be a rocket scientist.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 30 Sep 2008 17:44:58 -0400

For what it is worth, I fully agree with Ted here that the Reconfigure
Key Authentication Protocol (RKAP) should be used.

The option in this draft then would be more like the DHCPv6 Reconfigure
Accept option to negotiate Reconfigure support (no need for a data
byte). And, the draft would update RFC 3118 to define the RKAP.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Monday, September 22, 2008 5:45 PM
To: MILES DAVID
Cc: DHC WG
Subject: Re: [dhcwg] Accepting the following draft as WG work
item(pendingdiscussion)

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 1 Oct 2008 00:59:09 +0200

Ted, could you elaborate a bit more on the nonce option, and how you'd
see it working with 3118 and IPv4 Forced renew?

One of the arguments for removing the 3118 requirement from DHCP Forced
Renew is that the cost of implementing and scaling a 3118 implementation
with HMAC/MD5 is not trivial and not quite justifiable when it's use is
unwarranted.

-Woj. 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernie Volz (volz)
> Sent: 30 September 2008 17:45
> To: Ted Lemon; MILES DAVID
> Cc: DHC WG
> Subject: Re: [dhcwg] Accepting the following draft as WG 
> workitem(pendingdiscussion)
> 
> For what it is worth, I fully agree with Ted here that the 
> Reconfigure Key Authentication Protocol (RKAP) should be used.
> 
> The option in this draft then would be more like the DHCPv6 
> Reconfigure Accept option to negotiate Reconfigure support 
> (no need for a data byte). And, the draft would update RFC 
> 3118 to define the RKAP.
> 
> - Bernie
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> > would need to be in-line (between DHCP client and access node) to 
> > issue this renew and if a MITM approach was exploited the use of a 
> > nonce would be similarly vulnerable.
> 
> rejoinder, which was not countered, is that we can't assume 
> this protocol will be used only in TR-101 environments, and 
> therefore the minimal level of spoof-prevention offered by 
> the nonce security  
> I should say that I didn't use the correct name for the 
> authentication protocol I was recommending either in Dublin 
> or in my most recent  
> Reconfigure Key Authentication Protocol as described in 
> RFC3315 section 21.5.
> 
> > gateways vs. implementing a HMAC/MD5 function that would be 
> needed for 
> > a nonce/Reconfigure Key. This argument may be quite weak, but it is 
> > what motivated the creation of this draft.  It would seem 
> that either 
> > comparable security, so we preferred the easier option. That said, 
> > would you be willing to alter your view if a requirement was 
> > explicitly stated described a restricted L2 topology?
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Sep 2008 16:04:21 -0700

> see it working with 3118 and IPv4 Forced renew?

The protocol I'm talking about is the Reconfigure Key Authentication  
Protocol as described in RFC3315 section 21.5.   Could you read it  
over and let us know what you think?   Obviously I'm happy to answer  
any questions you may have.

> with HMAC/MD5 is not trivial and not quite justifiable when it's use  

Right, that was the motivation for the Reconfigure Key authentication  
protocol!   Obviously a protocol that requires each client to be  
configured with a shared secret doesn't scale, but that's not what  
we're talking about here.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 30 Sep 2008 19:05:51 -0400

I think if you read RFC 3315, you'll see how it works:

       21.5.  Reconfigure Key Authentication Protocol. . . . . . . .  68
              21.5.1. Use of the Authentication Option in the
                      Reconfigure Key Authentication Protocol. . . .  69
              21.5.2. Server considerations for Reconfigure Key
                      protocol . . . . . . . . . . . . . . . . . . .  69
              21.5.3. Client considerations for Reconfigure Key
                      protocol . . . . . . . . . . . . . . . . . . .  70

-----Original Message-----
From: Wojciech Dec (wdec) 
Sent: Tuesday, September 30, 2008 6:59 PM
To: Bernie Volz (volz); Ted Lemon; MILES DAVID
Cc: DHC WG
Subject: RE: [dhcwg] Accepting the following draft as WG

-Woj.