RE: Sensationalism? [was Re: FW: Man in the middle attack against RFC3456.]

["Darren Dukes" <ddukes@cisco.com>]

Dirk, the main point you can take from my posting this problem is that
RFC3456 has had relatively little mileage and implementation experience
compared to modecfg.  People have had years to discover the inherent
problems with modecfg and understand them, they've also had years to
understand how useful it can be.  RFC3456 is relatively young and not
entirely understood by this working group so there are likely many scenarios
where it will have problems that have not been discovered.

The one I pointed out is just one of those, will there be others?  Most
likely.  Should they be posted and discussed?  Absolutely.  Will they have
solutions that could change our understanding or implementation of RFC3456?
Who knows.

Dirk, you wrote.
> I would agree with you Darren, if this same scenario would work
> form the VPN
> client side because there is far less control on who is sitting behind the
> VPN client.

Why would it not work from a client?  If the selectors are such that all
traffic is tunnelled then a client could send DHCPACKs to the DHCP-relay on
the SGW, correct?

Thanks,
  Darren

> -----Original Message-----
> From: Van Aken Dirk [mailto:VanAkenD@thmulti.com]
> Sent: Thursday, February 06, 2003 6:06 AM
> To: 'Scott G. Kelly'; ddukes@cisco.com
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack
> against RFC3456.]
>
>
> I agree with Scott, IPSec is not going to solve this kind of security
> issues.
> i.e. IPSec was not conceived to cope with the situation where the
> frontdoor
> is open and where there is no backdoor.
> People having access to a central offices are assumed to be trusted !
>
> I would agree with you Darren, if this same scenario would work
> form the VPN
> client side because there is far less control on who is sitting behind the
> VPN client.
>
> If you can convice me that ModeCfg has no inherent limitations or that the
> DHCP based method has serious flaws, please tell me. If so, I'm willing to
> change my religion.
>
>
> BTW If IPSec must also cope with malicous insiders, then I know a very
> simple but effective attack on the security solution provided by a certain
> company ...
>
>
> > -----Original Message-----
> > From: Scott G. Kelly [mailto:scott@bstormnetworks.com]
> > Sent: woensdag 5 februari 2003 20:52
> > To: ddukes@cisco.com
> > Cc: ipsec@lists.tislabs.com
> > Subject: Sensationalism? [was Re: FW: Man in the middle attack against
> > RFC3456.]
> >
> >
> > 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
> >
> > Darren Dukes wrote:
> > >
> > > 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:ddukes@cisco.com]
> > > > Sent: Wednesday, February 05, 2003 12:10 PM
> > > > To: ipsec@lists.tislabs.com
> > > > 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
> > > >
> >