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

From: Van Aken Dirk <[email-masked]>
Date: Thu, 6 Feb 2003 13:33:11 +0100

Hi Scott,

You are correct that RADIUS is well entrenched in the ISP world.
Basically what it does is perform user authentication and depending on the
user profile, assigns a specific address to the user. This address comes
from a pool either managed by the RADIUS server itself or from a DHCP server
that is collocated with the RADIUS server.

Without RADIUS, the Access Servers must perform the user authentication
because protocols such as PPP are link layer (unless tunnelled in
L2TP/L2F/PPTP). Offloading this part of Access Servers is logical because
Access Servers are dedicated hardware devices. In addition a Service
Provider who has customers at different ISP's can centralize it's user
authentication service. Of course IP addresses still must come from the
individual ISP's pools in order to fit in the Internet routing structure.

However I'm intrigued how VPN fits into this scenario ? i.e. Am I going to
set-up a VPN session with my ISP ? In that way my traffic is encrypted
between me and the ISP but how does it travel from there ? Over an MPLS
cloud or is a new VPN tunnel set up to my corporate ? Additionally the
Virtual IP address that is assigned to the VPN client must belong to my
corporate LAN so is the ISP's RADIUS server going to manage an address pool
carved out of my corporate LAN address space ?

BTW, RADUIS has strong links with PPP and as said before, the IKEModeCFG
attributes have sticking resemblance with PPP hence  shares its limitations
...

Best regards - Dirk

> -----Original Message-----
> From: Scott Fanning [mailto:[email-masked]]
> Sent: donderdag 6 februari 2003 3:32
> To: Scott G. Kelly; [email-masked]
> Cc: [email-masked]
> Subject: Re: Sensationalism? [was Re: FW: Man in the middle attack
> against RFC3456.]
> 
> 
> 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.]
> 
> 
> > 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:[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: Van Aken Dirk <[email-masked]>
Date: Fri, 7 Feb 2003 09:54:46 +0100

Hi Darren,

See my comments below.

> Sent: donderdag 6 februari 2003 17:20
> To: Van Aken Dirk; 'Scott G. Kelly'
> Subject: RE: Sensationalism? [was Re: FW: Man in the middle attack
> against RFC3456.]
> 
> 
> 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.

Do not agree with the term "many" because RFC3456 is almost transparent to
IKE.

Setting up a tunnel for DHCP is not different from setting up a tunnel for
any other protocol.
The only difference is that the SPD/SAD selectors must contain the limited
broadcast address (255.255.255.255) and the default address 0.0.0.0. and of
course transport protocol UDP, destination ports/source port 67/68.

As said before, as soon as DHCP packets pass through the SPD, it is standard
IP/DHCP relay processing. If there would be a problem we would have heard it
by now because this technology has been proven over the years.
And that's the beauty of RFC3456, there is almost no interaction with IPSec
and the interaction can be done via standardized API/interfaces.

Of course on the point where there is interaction between DHCP/IKE/IPSec I
agree with you that one must be careful to not introduce side effects.

<trimmed ..>
> The one I pointed out is just one of those, will there be 
> others?

See my answer on your so called attack below.

What you doing here is trying to put RFC3456 in a negative daylight. i.e.
Using words such as "many", "one of those" and razing questions such as
"will there be others ?" you just try to scare/confuse the audience. Why
don't we look at the method in a positive way: the protocol is good until it
is has been proven otherwise ?

> Most likely.  Should they be posted and discussed? Absolutely.

Yes of course but in a positive way. Because up till now I heard all kind of
arguments against the solution, some of these being in a different protocol
layer.

> 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?

Yes, but then again have look at RFC3056 and how it can be applied.

FYI, 
- we use the Agent Circuit ID Sub-option to reference the tunnel via which
DHCP requests arrived into the system
- we put information into the Agent Remote ID Sub-option that is specific to
the relaying system and protected via cryptographic techniques.

As you will read in the RFC, the server must loop the complete contents of
the DHCP relay information option. Hence if we receive DHCP acks we can
easily check whether these are replies to original (relayed) requests or
not.

Over & out - Dirk