Subject: FW: Man in the middle attack against RFC3456.

From: "Darren Dukes" <[email-masked]>
Date: Wed, 5 Feb 2003 12:29:31 -0500

Amendment:
Eve sends the DHCPACK to the DHCP-relay (not the IRAC) with a manufactured
DHCP Relay Agent Information Option or one copied from a previous DHCP
message.

> -----Original Message-----
> From: Darren Dukes [mailto:[email-masked]]
> Sent: Wednesday, February 05, 2003 12:10 PM
> To: [email-masked]
> Subject: Man in the middle attack against RFC3456.
>
>
> There is a man in the middle attack on the DHCP-relay in RFC3456.
> This attack is based on the thread defined in RFC3118
> (DHCP-AUTH).  In this case Eve is inside the LAN and able to
> source DHCPACK packets, if Eve sends a DHCPACK to a an IRAC via a
> SGW implementing RFC3456 the DHCP-relay on the SGW will plumb a
> new route for whatever address Eve puts in yiaddr.
>
>                |-Eve
> IRAC ---- SGW -|
>                |-DHCP Server
>
> excerpt from RFC3456:
>    To learn the internal IP address of the client in order to route
>    packets to it, the security gateway will typically snoop the yiaddr
>    field within the DHCPACK and plumb a corresponding route as part of
>    DHCP Relay processing.
>
> This attack is not resolved by the implementation of RFC3118
> unless the following changes are made to the DHCP-relay.
> 1 - It stored a copy of all secret keys contained on the
> DHCP-server and used them to authenticate DHCPACKs or it stored a
> copy of the master key and used that to generate the client keys
> as described in RFC3118 Appendix A.
> 2 - DHCP-relay implements the DHCP-server replay protection.
>
>
> Darren
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 05 Feb 2003 11:51:56 -0800

Come on, Darren - you must be joking. What you describe is not an attack
against RFC3456 - it's an attack against DHCP/BOOTP, and this is nothing
new. If you run DHCP on your network and you have malicious insiders,
they can do all sorts of things. The same applies for most other
commonly run lan protocols. And since you've already conceded that a
scalable modecfg implementation will be running dhcp on the backend,
what is the point of this post? 

Let's stick with arguments with technical merit.

Scott

---

From: "Darren Dukes" <[email-masked]>
Date: Wed, 5 Feb 2003 15:31:57 -0500

Support of RFC3118 was significant enough for you to put in RFC3456, so why
is an illustration of the attack refuting that support called
sensationalism?  See RFC3456 Section 2.1 under "Authentication".

I think you're trivializing this.  RFC3456 has been touted as providing all
the modern and future capabilities of DHCP to IPsec clients.  This is one
case of how it fails to do this, and all it took to find was a few other
implementers taking a quick look at it yesterday.

If this attack has no technical merit then RFC3118 must not either (see
section 1.1).  RFC3118 exists to stop this sort of attack, so there must
have been a significant need for it otherwise why would the authors waste
their time writing it and advancing it to RFC?

If you can get rid of the necessity of snooping yiaddr in RFC3456 you can
fix this.

BTW modecfg with a DHCP-proxy will not suffer from this since the
DHCP-client implemented on the SGW could be provided with a single DHCP key.

Darren

> From: scott@nc600c-sk [mailto:scott@nc600c-sk]On Behalf Of Scott G.
> Kelly
> Sent: Wednesday, February 05, 2003 2:52 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Sensationalism? [was Re: FW: Man in the middle attack against
> RFC3456.]
>
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 05 Feb 2003 12:51:51 -0800

Forgive my skepticism, but this is nothing but a distraction. If you
have malicious insiders that will mount such attacks, you have serious
problems, and should not be depending on some weak dhcp auth scheme to
remedy this. Obvious solutions are to isolate the dhcp server, or to run
ipsec between the sgw and the dhcp server. Why are we wasting time on
this?

Enough said.

Scott

---

From: "Scott Fanning" <[email-masked]>
Date: Wed, 5 Feb 2003 18:32:12 -0800

In actuality, most service providers use RADIUS as a server to get ip
address, so how does DHCP fit in that (+ many other service provider
specific attributes)? Do we have to now translate between DHCP and RADIUS?
DHCP is not the only way to get addresses, but mode config allows the
security GW to be flexible on how ip addresses are acquired.

I also vote against the special SA. Having to create an SA, then to find out
that the ip address pool is exhausted, seems like alot of state to deal
with.

As for inside attacks, maybe you should talk to "security" experts who seem
to indicate that 59% of attacks are from the inside of the network.

"In the 2002 CPI/FBI survey, for instance, 59 percent of organizations
surveyed admitted to at least one internal attack."

Yeah, the RADIUS server is vulnerable too, but at least you don't waste QM
mode.

Anyway, my two cents. I am sure you will shoot it down. This is a good
debate. Too bad it was not this vigorous during the standardization process.
Oh yes, it was, but it was out of scope, out of charter.

Scott
----- Original Message -----
From: "Scott G. Kelly" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 05, 2003 11:51 AM
Subject: Sensationalism? [was Re: FW: Man in the middle attack against
RFC3456.]