Re: [saag] time to authenticate dhcp?

[Olafur Gudmundsson <[e-mail]>]

At 10:32 09/12/2008, Hallam-Baker, Phillip wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C959A3.A2E84306"
>
>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.

Background:
To some of us this is not a new problem but something that has
surfaced a few times in the past 10+ years.
Some of us have been arguing DHCP needs security,
see: (shameless plugs)
         http://tools.ietf.org/html/draft-ietf-dhc-security-requirements-00
         http://tools.ietf.org/html/draft-ietf-dhc-security-arch-01

The DHC working group decided that public key solutions were to
"heavy" and elected to go with shared secret authentication model.
The idea was that Public Key authentication could be added on later,
the question is that time now?

         Olafur



>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: [e-mail] on behalf of Michael Richardson
>Sent: Mon 12/8/2008 8:27 PM
>To: Steven M. Bellovin
>Cc: [e-mail]
>Subject: Re: [saag] time to authenticate dhcp?
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
> >>>>> "Steven" == Steven M Bellovin <[e-mail]> 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>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[
>] [e-mail] 
><http://www.sandelman.ottawa.on.ca/>http://www.sandelman.ottawa.on.ca/ 
>|device driver[
>] panic("Just another Debian GNU/Linux using, kernel hacking, 
>security guy"); [
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.6 (GNU/Linux)
>Comment: Finger me for keys
>
>iQEVAwUBST3Ji4CLcPvd0N1lAQJn/Af/RuJWzBQfJYml9d9wHVs2ur3caJ9K1ISJ
>ps+zHKKYfFkw0KDDk+a3Km62xNlF7Lf7fPoZ+u4t20u6GobuJeR3NGZTOGYbjHsK
>UDduBVi/I9vEXZBd9k/tunqw89c4lGqQN7XbORq+vbLLUWmcdsnYwaMAFPI3jhZp
>ma7hYnX+7Vfg+5zNYtMqkhhFXfF6pbeQeu9HtpHcdEex/lTWlnCUpE3Qjb4BLlG8
>ymPNA9cgpwFlWUgi7oZ6KHZ2K1Nro0tuIqLtllstR/e1RQHz6owOsHOLYVjql40i
>kkcwU4/tgjW8I3hBxckvPzc+29ipsB8UN7NO3qJu1YYKEF4h+qDvrQ==
>=fPHj
>-----END PGP SIGNATURE-----
>_______________________________________________
>saag mailing list
>[e-mail]
><https://www.ietf.org/mailman/listinfo/saag>https://www.ietf.org/mailman/listinfo/saag
>
>_______________________________________________
>saag mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/saag

_______________________________________________
saag mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/saag