Subject: [dhcwg] draft-ietf-dhc-forcerenew-nonce-00

From: "Alper Yegin" <[email-masked]>
Date: Thu, 7 Jan 2010 18:02:24 +0200

Hello,

I'm trying to understand the applicability of this solution.

The I-D starts with telling why RFC 3118 cannot be used:

   Authentication for DHCP [RFC3118] is
   mandatory for Forcerenew, however as it is currently defined
   [RFC3118] requires distribution of constant token or shared-secret
   out-of-band to DHCP clients.

And it concludes depending on RFC 3118 again:

   As in some network environments FORCERENEW can be used to snoop and
   spoof traffic, the FORCERENEW message MUST be authenticated using the
   procedures as described in [RFC3118] or this proposal.

If the network is protected against spoofing/snooping, then there is no need
for securing FORCERENEW at the DHCP level.

If the network is not protected against spoofing/snooping, then passing a
key in clear and using it later does not secure FORCERENEW either.

Am I missing something?

Alper

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 7 Jan 2010 17:17:32 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Alper Yegin
> Sent: 07 January 2010 17:02
> To: 'dhc WG'
> Subject: [dhcwg] draft-ietf-dhc-forcerenew-nonce-00
> 
> Hello,
> 
> If the network is protected against spoofing/snooping, then 
> there is no need for securing FORCERENEW at the DHCP level.

Indeed, the original itent (c.a. IETF 72 or so) of the proposal was to
make the use of rfc3118 along with FORCERENEW "optional" in some network
environments. Feedback we received suggested that instead of doing that
it would be better to make the existing FORCERENEW with rfc3118
mechanism trivial by means of using the nonce.

-Woj.

> 
> If the network is not protected against spoofing/snooping, 
> then passing a key in clear and using it later does not 
> secure FORCERENEW either.
> 
> Am I missing something?
> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Jan 2010 09:49:48 +0200

> environments. 

Today DHCP is secured by relying on lower-layer security mechanisms. That's
how it gets by without using RFC 3118. The same network conditions can also
secure FORCERENEW. IMHO acknowledging that is better than defining this
flawed solution.

> Feedback we received suggested that instead of doing that

It gives the false sense of security, hence becomes harmful.

Alper

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 8 Jan 2010 15:37:32 +0700

Alper Yegin [mailto://[email-masked]] writes:

> Today DHCP is secured by relying on lower-layer security mechanisms.

That's an interesting statement.  Can you be more specific about those
mechanisms WRT Ethernet, for example?

> That's

How true.

...

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 8 Jan 2010 09:58:46 +0100

Hello Alper,

> secure FORCERENEW. IMHO acknowledging that is better than defining this

The solution described in the current version of the draft reflects the same approach defined for DHCPv6 Reconfigure message as it was suggested in Dublin IETF-72 and in the mailing list, please see links below:
http://tools.ietf.org/wg/dhc/minutes?item=minutes72.html
http://www.ietf.org/mail-archive/web/dhcwg/current/msg08510.html

Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: Friday, January 08, 2010 8:50 AM
To: 'Wojciech Dec (wdec)'; 'dhc WG'
Subject: Re: [dhcwg] draft-ietf-dhc-forcerenew-nonce-00

Alper

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 8 Jan 2010 10:49:28 +0100

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: 08 January 2010 08:50
> To: Wojciech Dec (wdec); 'dhc WG'
> Subject: RE: [dhcwg] draft-ietf-dhc-forcerenew-nonce-00
> 
> > > If the network is protected against spoofing/snooping, 
> then there is 
> > > no need for securing FORCERENEW at the DHCP level.
> > 
> > make the use of rfc3118 along with FORCERENEW "optional" in some 
> > network environments.
> 
> Today DHCP is secured by relying on lower-layer security 
> mechanisms. That's how it gets by without using RFC 3118. The 
> same network conditions can also secure FORCERENEW. IMHO 
> acknowledging that is better than defining this flawed solution.
> 
> it would be 
> > better to make the existing FORCERENEW with rfc3118 
> mechanism trivial 

Well, it's a compromise that allows us not to modify the original
forcerenew spec, but rather build on it to fit the scenario where
man-in-the-middle attacks are prevented through other means (eg running
in an implicitly trusted domain).
As stated in the security considerations this method does not claim to
offer security, and fully keyed 3118 should be used if that's needed.

-Woj.

> 
> Alper
> 
> 
> > 
> > -Woj.
> > 
> > >
> > > If the network is not protected against spoofing/snooping, then 
> > > passing a key in clear and using it later does not secure 
> FORCERENEW 
> > > either.
> > >
> > > Am I missing something?
> > >
> > > Alper
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Jan 2010 12:15:55 +0200

The concern is that a rogue host connecting to the access network can spoof
FORCERENEWs, right?
The solution is to put filters on the L2 access device to drop such packets
coming from the attached hosts.

> From: Glen Zorn [mailto:[email-masked]]
> Sent: Friday, January 08, 2010 10:38 AM
> To: 'Alper Yegin'
> Cc: 'Wojciech Dec (wdec)'; 'dhc WG'
> > > network
> > how it gets by without using RFC 3118. The same network conditions
> can
> > also

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 11 Jan 2010 10:22:42 +0200

> offer security, and fully keyed 3118 should be used if that's needed.

Sorry, this makes no "technical" sense to me. Obviously it is not solving
the problem it intends to solve (namely, ability to secure FORCERENEW in the
absence of lower-layer security and properly keyed RFC 3118).

Alper

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 11 Jan 2010 10:08:41 +0100

> Sent: 11 January 2010 09:23
> mechanisms. 
> > > That's how it gets by without using RFC 3118. The same network 
> > > conditions can also secure FORCERENEW. IMHO acknowledging that is 
> > > better than defining this flawed solution.
> > >
> > man-in-the-middle attacks are prevented through other means (eg 
> > running in an implicitly trusted domain).
> Sorry, this makes no "technical" sense to me. Obviously it is 
> not solving the problem it intends to solve (namely, ability 
> to secure FORCERENEW in the absence of lower-layer security 
> and properly keyed RFC 3118).

That's not quite the problem it's solving (securing FORCERENEW in the
absence of lower layer security). It's rather meant to offer a trivial
(no key management) means of using FORCERENEW without chainging it's
spec in deployments where man in the middle attacks are not a threat.
This I suppose means that we should elaborate a bit more on the problem
statement in the next revision of the draft. For some history please
read though the minutes
http://www.ietf.org/mail-archive/web/dhcwg/current/msg08823.html related
to draft draft-vinokour-dhcp-reconfigure-option.

-Woj.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Jan 2010 11:23:50 +0200

I think we all are on the same page about RFC 3118 being a non-starter 
and needing more light weight solutions for most situations. The "no 
security at all" and "perfect security" models aren't very useful... 
because "perfect security" is undeployable we've fallen back on "no 
security at all". The question is, what light weight solution is 
appropriate?

I think the nonce solution is a reasonable piece of engineering. But I'm 
not sure I fully understand what other things we could be doing, are 
already doing, or how this solution compares to them. For instance, if 
you were blocking server-originated DHCP messages from hosts in the 
switch / AP, would this solution bring additional value? Under what 
assumptions does this solution provide additional protection? Only when 
attackers are not all the time on the same network? Or are there also 
situations where its hard for an attacker to see the message with the 
original nonce value but easy to send a spoofed FORCERENEW, even if the 
attacker is present all the time?

As a first step, perhaps the document could be clearer about what 
specific scenarios it can address.

Jari

---

From: Ralph Droms <[email-masked]>
Date: Fri, 15 Jan 2010 08:41:48 -1000

Jari - brief responses in line...

- Ralph

On Jan 14, 2010, at 11:23 PM 1/14/10, Jari Arkko wrote:

> I think we all are on the same page about RFC 3118 being a non- 
> starter and needing more light weight solutions for most situations.  
> The "no security at all" and "perfect security" models aren't very  
> useful... because "perfect security" is undeployable we've fallen  
> back on "no security at all". The question is, what light weight  
> solution is appropriate?

And, there hasn't been a strong consensus that DHCP security needs to  
be provided by extensions to DHCP itself.  There are some more-or-less  
common practices that can protect against rogue attacks originating  
from the link to which the DHCP client/host is attached.  While there  
may be other attack exposures, I believe they are sufficiently similar  
to other attacks that the usual "network hygiene" filtering traffic  
from external sources provides sufficient security.

> I think the nonce solution is a reasonable piece of engineering. But  
> I'm not sure I fully understand what other things we could be doing,  
> are already doing, or how this solution compares to them. For  
> instance, if you were blocking server-originated DHCP messages from  
> hosts in the switch / AP, would this solution bring additional  
> value? Under what assumptions does this solution provide additional  
> protection? Only when attackers are not all the time on the same  
> network?

In order: yes, when the attacking traffic comes in through the  
"trusted" network and interface on the link switch, yes.

> Or are there also situations where its hard for an attacker to see  
> the message with the original nonce value but easy to send a spoofed  
> FORCERENEW, even if the attacker is present all the time?

The only protection for FORCERENEW, at present, is RFC 3118  
authentication.  Without that authentication, any attacker can send a  
FORCERENEW "blindly" at a DHCP client/host.  With the nonce, the  
attacker needs to read the message in which the nonce is exchanged.

> specific scenarios it can address.

That clarity would be good.

> Jari

- Ralph

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 20 Jan 2010 21:13:47 -0800

Ralph,

> "trusted" network and interface on the link switch, yes.

When RFC 3118 is not used even though there can be rogue nodes in the
trusted network (I'm recapping the scenario you are describing), isn't the
whole DHCP vulnerable? I mean, how does it help if you secure FORCERENEW
when none of the other DHCP packets are secured? 

> attacker needs to read the message in which the nonce is exchanged.

How difficult is that? Rogue node could be sniffing the air, receiving the
multicast packets, and even be in the trusted network (and acting like a
legitimate DHCP server).

---

From: Ralph Droms <[email-masked]>
Date: Wed, 20 Jan 2010 15:08:56 -0500

Alper - The primary difference is that FORCERENEW can be sent  
asynchronously by a server, while all other messages from a server are  
sent in response to a message from a client.  So, it's easier to  
attack a host through an arbitrary FORCERENEW message rather than  
correctly timing a spoofed response message.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Jan 2010 16:20:36 -0700

> when none of the other DHCP packets are secured? 

If your network doesn't have ingress filtering, it would be possible for an off-network attacker to send a DHCPFORCERENEW to a device that it expects could be attached to the network.   Without something like a nonce, the client would have no way to distinguish a forged DHCPFORCERENEW from a legitimate one.

This is worth doing because it's much easier to get a client to swallow a forged DHCPOFFER or DHCPACK if you can predict when it will be expecting it.   Getting a client to swallow a DHCPACK from an off-network attacker would be a real jackpot, because the attacker could then, for instance, arrange for the client to resolve DNS queries through it.

Without DHCPFORCERENEW, an off-network timing-based attack would be virtually impossible, because the client isn't ordinarily listening for DHCPACKs.   But a client that supports DHCPFORCERENEW is _almost always_ listening for a DHCPFORCERENEW.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 28 Jan 2010 11:46:02 -0800

Ted,

In your scenario where you find FORCERENEW-nonce solution useful, the
attacker is:
1- Able to know the IP address of the DHCP server the victim was using,
2- Able to know the IP address of the victim host,
3- Able to inject a bogus DHCP packet into the network towards the victim,
with the spoofed source address set to DHCP server's IP address.

What I'm saying is, if you have an attacker with such capabilities, stopping
his FORCERENEW with nonce has no value. He can most probably still attack
using other DHCP packets. Because, if he can do [1] and [2], then he is most
probably inside the same LAN as the victim host is (unless the attacker is
doing a brute-force attack, or has insider information).

...

And, my point is, I cannot think of a network that would care about
implementing FORCERENEW-nonce on "all DHCP clients and DHCP servers", but
not implement/enable measures against [3] on "all L2 edge devices". Not
doing the latter means that any host connected to the LAN can mess with DHCP
(even in the presence of this FORCERENEW-nonce).

I'm afraid I'm repeating myself...

Alper

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Wednesday, January 20, 2010 3:21 PM
> To: Alper Yegin
> Cc: 'Ralph Droms'; 'Jari Arkko'; 'dhc WG'
> If your network doesn't have ingress filtering, it would be possible
> for an off-network attacker to send a DHCPFORCERENEW to a device that
> it expects could be attached to the network.   Without something like a
> nonce, the client would have no way to distinguish a forged
> DHCPFORCERENEW from a legitimate one.
> 
> This is worth doing because it's much easier to get a client to swallow
> a forged DHCPOFFER or DHCPACK if you can predict when it will be
> expecting it.   Getting a client to swallow a DHCPACK from an off-
> network attacker would be a real jackpot, because the attacker could
> then, for instance, arrange for the client to resolve DNS queries
> through it.
> 
> Without DHCPFORCERENEW, an off-network timing-based attack would be
> virtually impossible, because the client isn't ordinarily listening for
> DHCPACKs.   But a client that supports DHCPFORCERENEW is _almost
> always_ listening for a DHCPFORCERENEW.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 28 Jan 2010 10:55:37 +0100

I disagree with your premise that the three conditions you describe  
result in a host that is as susceptible to attack by other DHCP  
messages as by FORCERENEW.

FORCERENEW is sent asynchronously by the server, so the host is  
expected to process a FORCERENEW receive at any time.  All other  
messages from a server are sent only in response to a message from the  
client, so an attack using one of these other messages must be timed  
to arrive during the window between the time the message is sent by  
the client and the time the real response from the server is received  
by the client.  As that window is small - e.g., at most few seconds a  
day if the client is assigned an address with a 24 hour lease - it is  
highly unlikely random attacks will be successful.  And, unless the  
attacker has some knowledge of the time at which the client sends a  
message to the server - which you do not postulate - the attacker has  
no way to time the transmission of its attack into that small window.

Therefore, the FORCERENEW message does represent a more easily  
utilized threat to a DHCP client than other DHCP messages.

- Ralph

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 28 Jan 2010 15:55:36 -0800

Ralph,

The thinking is, FORCERENEW by the attacker is followed by the attacker
responding to follow-up DHCP messages hence the victim gets spoofed info,
right?

So, the attacker is in the same LAN as the victim is. Correct?

In that case, the attacker could already respond to the very first
DHCPDISCOVER and fool the victim all along. 

Alper

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Thursday, January 28, 2010 1:56 AM
> To: Alper Yegin
> Cc: Ted Lemon; Jari Arkko; dhc WG

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 28 Jan 2010 10:05:27 -0500

> FORCERENEW by the attacker is followed by the attacker responding to
follow-up DHCP messages hence the victim gets spoofed info, right?

It might also be used for a denial of service attack. Get as many DHCP
clients back to the INIT state as possible, overwhelm the local DHCP
server with DISCOVER traffic, and thus knock out service for as many
computers as possible. Then the attacker doesn't have to be on the same
LAN.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alper Yegin
Sent: Thursday, January 28, 2010 6:56 PM
To: 'Ralph Droms'
Cc: 'dhc WG'; 'Ted Lemon'
Subject: Re: [dhcwg] draft-ietf-dhc-forcerenew-nonce-00

Ralph,

The thinking is, FORCERENEW by the attacker is followed by the attacker
responding to follow-up DHCP messages hence the victim gets spoofed
info,
right?

Alper

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Jan 2010 08:25:53 -0700

> computers as possible. Then the attacker doesn't have to be on the same

Also, as has been proven in cases like DNS, even if you don't know what the exact data is, you can flood the network with guesses.   So you don't have to be on-link to attempt an attack.   And we aren't using any cryptographic entropy here, so if you know enough about the network to make educated guesses, you can definitely attempt an attack, and FORCERENEW makes such an attack many orders of magnitude easier, because, as Ralph says, the client is always listening for a FORCERENEW, whereas the window of opportunity for an attack using any other DHCP message is very brief and infrequent.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 29 Jan 2010 01:09:10 +0900

In general sending a shared key in clear text and later on 
using it for message authentication is considered to be a 
security hole.

Yoshihiro Ohba

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Jan 2010 10:56:32 -0700

> using it for message authentication is considered to be a 

This document specifically addresses the concern that an attacker could do a blind attack from off-network.   To prevent on-network attacks it would be necessary to implement RFC3118-style authentication.   I don't think the document claims to prevent on-network attacks; if it does, it needs to be updated to be more clear.

The point is to make attacks like the one that Dan Kaminsky publicized for DNS cache poisoning prohibitively expensive, *not* to authenticate the DHCP message.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 29 Jan 2010 03:52:29 +0900

> The point is to make attacks like the one that Dan Kaminsky publicized for DNS cache poisoning prohibitively expensive, *not* to authenticate the DHCP message.

OK, I found myself get confused with the very first sentence 
in Introduction:  "This document defines extensions to 
Authentication for DHCP(v4) Messages [RFC3118] to create a 
new authentication protocol for DHCPv4 Forcerenew [RFC3203] 
messages."

I think this statement needs to be revised if the point of 
this proposal is not to authenticate the DHCP message.

Thanks,
Yoshihiro Ohba

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Jan 2010 14:45:16 -0700

Ah, good point.  I think the draft definitely needs more clarity on  
what it is for. We kind of railroaded Woj onto doing it this way, and  
I think that's a big part of the problem.   I will try to find some  
time to suggest text this weekend.

On Jan 28, 2010, at 11:52 AM, Yoshihiro Ohba <[email-masked] 
 > wrote:

>> This document specifically addresses the concern that an attacker  
>> could do a blind attack from off-network.   To prevent on-network  
>> attacks it would be necessary to implement RFC3118-style  
>> authentication.   I don't think the document claims to prevent on- 
>> network attacks; if it does, it needs to be updated to be more clear.
>>
>> The point is to make attacks like the one that Dan Kaminsky  
>> publicized for DNS cache poisoning prohibitively expensive, *not*  
>> to authenticate the DHCP message.
>>
>>
>