Subject: [saag] time to authenticate dhcp?

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 8 Dec 2008 17:38:39 -0500

http://voices.washingtonpost.com/securityfix/2008/12/a_scary_twist_in_malware_evil-.html?nav=rss_blog

But how, in a public setting?  How can "Steve" (to use the name from
the article) *realistically* tell his laptop the proper public key to
expect?

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 08 Dec 2008 17:41:21 -0500

> the article) *realistically* tell his laptop the proper public key to

After reading the article, it seems like the only real fix to the
problem described is to accelerate widespread deployment of DNSsec...

Yours,

Ran

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 8 Dec 2008 14:55:02 -0800

That is not necessarily enough.

The critical weakness here is the braindamaged idea that you take DNS from the local network that offers it. I am happy to collect IP packets from Panera, but why would I rely on them for my DNS server to resolve cnn.com?

-----Original Message-----
From: [email-masked] on behalf of RJ Atkinson
Sent: Mon 12/8/2008 5:41 PM
To: Steven M. Bellovin
Cc: [email-masked]
Subject: Re: [saag] time to authenticate dhcp?

Yours,

Ran

---

From: Mark Baugher <[email-masked]>
Date: Mon, 8 Dec 2008 14:59:50 -0800

The near-term solution is to VPN to a network you trust for names and  
addresses.

Mark

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Dec 2008 18:08:07 -0500

--On Monday, December 08, 2008 02:55:02 PM -0800 "Hallam-Baker, Phillip" 
<[email-masked]> wrote:

> The critical weakness here is the braindamaged idea that you take DNS
> from the local network that offers it. I am happy to collect IP packets
> from Panera, but why would I rely on them for my DNS server to resolve
> cnn.com?

Because they're in the best position to provide caching, and you shouldn't 
be in a position where your security depends on getting the correct answer 
to questions about cnn.com (even if you work for cnn.com).

But yes, another solution is to use TSIG and send all of your DNS traffic 
to a server you trust.  Of course, that works for you and me, but not for 
joe random internet user, who doesn't have any routable addresses at his 
disposal.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Dec 2008 15:29:21 -0800

>>>>> On Mon, 8 Dec 2008 17:38:39 -0500, "Steven M. Bellovin" <[email-masked]> said:

SMB> But how, in a public setting?  How can "Steve" (to use the name
SMB> from the article) *realistically* tell his laptop the proper public
SMB> key to expect?

As everyone on this list knows, you always have to have pre-existing
knowledge in order to trust something.  This could come from a number of
forms:

1) leap-of-faith

   (ssh style: trust the offerer the first time, hopefully when no one
   else is in the coffee shop or by verifying it based on their public
   web page before you leave the house)

   (Then blindly accept it again when it changes because you know
   everyone will)

2) DNSSEC

   A number of us have been arguing for DNSSEC resolution directly on
   the client.  Without doing resolution on the client you've gained
   nothing.  There are a lot of people that don't want the maintenance
   headache though so you're back to square one if you're expecting a
   validating resolver in the coffee shop to take care of you.

3) Routing infrastructure

   I'm not a routing expert which means I'm just dangerous.  I believe
   there is work in progress in the routing area to sign IP address
   ownership with public certificates.  This obviously doesn't work when
   the local coffee shop is using a 10/8 address or similar pool
   though.  So they'll need to switch to IPv6.  This doesn't stop,
   however, the evil coffee company from coming into the good coffee
   companies free space and advertise routes through them.
   Unfortunately, X.509 cert doesn't have the evil bit that verifies
   you'll do no harm with the certificate.

Thus, we only need to pick one of:

- educate users to do leap of faith or pre-authentication properly
- deploy DNSSEC in all devices with properly maintained trustanchors
- Develop trustable routing ownership down to the end user over
  widely-deployed IPv6

Easy!

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 8 Dec 2008 15:54:35 -0800

It should all just be part of an Internet service.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Dec 2008 20:27:41 -0500

>>>>> "Steven" == Steven M Bellovin <[email-masked]> writes:
    Steven> But how, in a public setting?  How can "Steve" (to use the
    Steven> name from the article) *realistically* tell his laptop the
    Steven> proper public key to expect?

  He can't until he is online to look it up.  Naming it is easy.

  Once online, he can confirm it.  What key?  Why a DHCPKEY(tbd) or
perhaps a DNSKEY in the in-addr.arpa for the DHCP server's IP. 
  See www.wavesec.org.
  
  Also see
     http://www.sandelman.ca/SSW/ietf/dhc/draft-richardson-dhc-auth-sig0-00.txt

  which never got enough enthusiam to bother going forward (nor enough
cycles from the freeswan team)

  Note that given a trusted anchor for in-addr.arpa (whether signed .,
or DLV for in-addr.arpa, or whatever), you can confirm key.  If your
local DNS cache is not empty, you may already be able to authenticate
it.
  If the machine doing a MITM on your DHCP server is doing such a good
job of emulating the rest of the Internet that things check out, then I
would suggest that you really are on the Internet :-)

  Note that of course, this completely fails when your DHCP server is
192.168.1.1.   Is there some way to use the outer IP of the router in
the cafe?  

  But, if you postulate IPv6, you might as well postulate SEND as well.

  As far as I can tell, this "DNSChanger", "DHCPChanger" attack is
completely untouched by using 802.1x/WPA/WPA2 "security", because the
layer3 is not bound (as in channel bound) to the layer2 security.

- -- 
]      Y avait une poule jammer dans le muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 8 Dec 2008 18:12:50 -0800

I think that this particular conversation has gone from problem to solution to quickly. Or rather we skipped straight from an attack to a patch to defeat that one attack.

I think Steve was right to ask the question whether we should think about DHCP security. But we should do that by thinking about the security properties we rely on from DHCP and might want to rely on in future.

In particular I think that we could do to think in terms of a secure handshake for a client connecting to a WiFi node. Should we be putting the security in the DHCP layer or somewhere else? Should a DHCP handshake in Panera be equivalent to a DCHP handshake on a home network?

What assets are involved here? What are the intrinsic risks that affect those assets? Lets start thinking about the security of the systems that a user is engaged in, not just ad hoc patches to fix one attack.

-----Original Message-----
From: [email-masked] on behalf of Michael Richardson
Sent: Mon 12/8/2008 8:27 PM
To: Steven M. Bellovin
Cc: [email-masked]
Subject: Re: [saag] time to authenticate dhcp?

  
  Also see

- --

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 10 Dec 2008 03:24:58 +0200

The simple solution would be to filter certain types of packets on the WiFi
access point (AP) based on the ingress interface. For example, AP shall be
configured to drop any DHCPOFFER packets received on the 802.11 interface
(untrusted public side), and allow those received on the 802.3 interface
(trusted intra-net side). That way a visiting host cannot inject a DHCP
packet towards the other hosts.

Note that, even if you secure DHCP there are other similar attacks to trick
the victims leveraging ARP/ND and router discovery, unless those are secured
as well. Filtering can be applied there as well. 

Alper

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 9 Dec 2008 21:30:09 -0600

> layer3 is not bound (as in channel bound) to the layer2 security.

Interesting point.  I'm not sure that anyone would be interested in
building such a binding, and even we had it, when you use any random
cafe's network there's nothing in L2 security that can help you
establish trust in its DNS cache servers -- you still need DNSSEC.

Also, such a binding would be simply another DNS bandaid.  We need
DNSSEC.  (Although even just enlarging the DNS XID, if we could, would
help enormously.  I have not followed the DNS lists for a long time, so
I don't know if anything's been tried w.r.t. enlarging the DNS XID.)

Nico

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 Dec 2008 21:23:35 -0800

Indeed.   For example, a wireless base station could drop the following incoming packets on 
the wireless link:

1. IPv6 Router Advertisement packets (ICMP Type 134)
2. DHCPv4 packets sent to the client port (68)
3. DHCPv6 packets sent to the client port (546)

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 10 Dec 2008 01:14:12 -0600

> I don't know if anything's been tried w.r.t. enlarging the DNS XID.)

Stupid question(?): couldn't we define an echo/reply RR type as a way to
add a larger XID to DNS?  The RR name would be a long, randomly-
generated string, acting as an extended XID.

Follow-up stupid question(?): until such an RR type is specified and
deployed, couldn't one use a convention for naming a special name for
which one expects an NXDOMAIN result?  This would be an approximation of
an echo/reply RR type.

The difference between an approximation and a real echo/reply RR type
would be that caching servers would know about the echo/reply RR type
and put in their own reply (and use different extended XIDs, if I may
call them that, in their own queries to other servers).  E.g., query for
exid<long-random-string>.<domain>, type any, expect NXDOMAIN.

Of course, clients couldn't count on this until servers that implement
such a thing are widely deployed.  An DNSSEC deployment would render the
need for extended XIDs moot.  But it'd have been great if in the
randomized port patching frenzy we could have added support for extended
XIDs.

Nico

---

From: <[email-masked]>
Date: Wed, 10 Dec 2008 10:59:46 +0200

As far as I know, many existing WiFi APs (those intended for public
access/enterprise use, not home APs) already do what you're
proposing, and similar filtering for ARP. SAVI WG is working
on standardizing that behavior.

Best regards,
Pasi 

> From: Alper Yegin
> Sent: 10 December, 2008 03:25
> To: 'Steven M. Bellovin'
> Cc: [email-masked]
> The simple solution would be to filter certain types of packets on
> the WiFi access point (AP) based on the ingress interface. For
> example, AP shall be configured to drop any DHCPOFFER packets
> received on the 802.11 interface (untrusted public side), and allow
> those received on the 802.3 interface (trusted intra-net side). That
> way a visiting host cannot inject a DHCP packet towards the other
> hosts.
> 
> Note that, even if you secure DHCP there are other similar attacks
> to trick the victims leveraging ARP/ND and router discovery, unless
> those are secured as well. Filtering can be applied there as well.
> 
> 
> Alper

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Dec 2008 09:06:36 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    >> completely untouched by using 802.1x/WPA/WPA2 "security", because
    >> the layer3 is not bound (as in channel bound) to the layer2
    >> security.

    Nicolas> Interesting point.  I'm not sure that anyone would be
    Nicolas> interested in building such a binding, and even we had it,
    Nicolas> when you use any random cafe's network there's nothing in
    Nicolas> L2 security that can help you establish trust in its DNS
    Nicolas> cache servers -- you still need DNSSEC.

  ... layer-3 security.  That's why I find WPA/etc. such a waste of
time.  We need security that applications can find and trust.

-- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Dec 2008 09:07:26 -0500

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:
    Bernard> Indeed.  For example, a wireless base station could drop
    Bernard> the following incoming packets on the wireless link:

    Bernard> 1. IPv6 Router Advertisement packets (ICMP Type 134)
    Bernard> 2. DHCPv4 packets sent to the client port (68) 3. DHCPv6
    Bernard> packets sent to the client port (546)

  You mean, create more deep packet inspection requirements in
intermediate nodes to get around the lack of end-to-end security?

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 10 Dec 2008 10:50:02 -0500

On Tue, 2008-12-09 at 21:23 -0800, Bernard Aboba wrote:
> For example, a wireless base station could drop the following incoming
> packets on the wireless link:
> 

That doesn't make things worse, but it also doesn't help if the
attacker's system is acting as a base station (bridging selected traffic
through to the legitimate base station).

							- Bill

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Dec 2008 08:03:10 -0800

Yes, hotspot and enterprise class APs typically do support IP filtering and have
for quite a while.  Some of the open source AP distributions suitable for home use
also support IP filtering. 

> Date: Wed, 10 Dec 2008 10:59:46 +0200
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Dec 2008 09:52:10 -0800

>generated string, acting as an extended XID.

Not a stupid question, but SAAG is the wrong mailing list for this: this is pertinent to the DNSEXT WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 11 Dec 2008 01:49:07 +0200

> through to the legitimate base station).

The rogue entity inserting itself between the victim host and legitimate
base station (Mitm) is a much harder attack. So, the filtering has
considerable value.

Furthermore, one way to address this "MitM" attack is to use L2 access
authentication. That way the host knows it is connected to a legitimate
network. Even than (when your attack scenario is out of our way), the
aforementioned filtering is needed so that other authenticated on-link hosts
cannot inject the bogus DHCP/ARP/ND packets to the network. 

Alper

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 11 Dec 2008 11:04:21 -0500

--On Thursday, December 11, 2008 01:49:07 AM +0200 Alper Yegin 
<[email-masked]> wrote:

> network.

What's a "legitimate network"?  I don't share any authentication secrets 
with my local Panera Bread.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Dec 2008 17:36:19 -0600

> this is pertinent to the DNSEXT WG.

Looking at the namedroppers list archive, the idea has been discussed
already, in various independent threads, and apparently many have come
up with much the same idea independently.  I'm just late to that party :)

Nico

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 12 Dec 2008 02:54:06 +0200

> with my local Panera Bread.

I was referring to "L2 authentication." In cases where L2 authentication is
used, you host has either a PSK with the WiFi AP (e.g., home gateway), or a
PSK/cert with a AAA server that has a direct (or hop-by-hop) PSK with the
AAA client on the AP (e.g., enterprise/operator WiFi). 

Alper

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 12 Dec 2008 03:54:39 -0500

On Fri, 12 Dec 2008 02:54:06 +0200
"Alper Yegin" <[email-masked]> wrote:

> I was referring to "L2 authentication." In cases where L2
> authentication is used, you host has either a PSK with the WiFi AP
> (e.g., home gateway), or a PSK/cert with a AAA server that has a
> direct (or hop-by-hop) PSK with the AAA client on the AP (e.g.,
> enterprise/operator WiFi). 
> 
Again, what about Panera?  They don't charge; they don't have much need
for that sort of infrastructure.

Besides, how do people register in the first place?  Is this the real
AP, or is it an evil twin pointing at a credit card-stealing service?

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 12 Dec 2008 07:25:57 -0800

As I said earlier, lets look at the system. 

Steve is right here, we need to start from a use case and work out the security requirements. The problem here is to provide security to real people in real situations. If we just look at one particular attack and jump to securing DHCP we will still be stuck in a reactive mode that is ineffective in dealing with organized crime.

Lets take Alice goes to Panera as a use case and look for ways to meet the whole needs of the system, including Panera's need to be able to present terms and conditions and possibly employ mechanism to limit access to actual customers. And also including the need to integrate strong encryption into the wireless link itself because not every Internet protocol and server has application layer security.

And then lets consider the subtly different use case of Joe's coffee house that nobody really knows and does not have a trusted brand, or an extended network of shops.