Re: protocol support for intercepting proxies

I've just spent most of the day reading DHCP RFCs.  There are still 
numerous problems with DHCP, even apart from issues with current 
implementations.

The home page of the DHC WG outlines a number of issues, the one at the 
top of their list being "address security in DHCP". 

http://www.ietf.org/html.charters/dhc-charter.html

They state no-one has implemented RFC 3118 (DHCP-AUTH).  Given that RFC 
3118 has been out for 6 years, that may have something to do with trying 
to auth at too low a level in the stack.  Same reason IP auth options 
were chucked out.  Auth fundamentally requires sharing of secrets.  It's 
unmanageable to share secrets (esp on a large scale) without using 
networking protocols (i.e. you'd need to use sneakernet).  Therefore 
DHCP can't effectively or efficiently be authed, since it sets up the 
networking protocols that would be used for sharing secrets, and 
therefore "DHCP Auth" is a chicken-and-egg paradox.  You'd need an 
ethernet (non IP) level key management / auth subsystem to auth DHCP.  
One that can cross subnets.  Since most routers are IP routers, ethernet 
level is a non-starter as well.  You really need an IP level or higher 
protocol for auth.

So I don't see security issues with DHCP being solved any time soon.  
It's a hard problem.

Furthermore when they created the DHCPINFORM message, they neglected to 
make it usable by client applications other than the OS DHCP client 
(since they didn't relax the requirements for the destination port that 
the unicast DHCPACK would be sent to - it woulda been sooo easy to allow 
that to be sent back to the source port of the agent that sent the 
DHCPINFORM message, but no - port 68 is it).  That's only the start of 
the problems with the DHCPINFORM message as well - a DHCP server is even 
prohibited from making certain security decisions about whether it will 
reply (prohibited from verifying that the DHCP client is a known client).

The relevance here is that WPAD's primary method is based on the 
DHCPINFORM message.

In my experience, opportunity for reliable security improves as you move 
up the stack (*), and degrades as you go down it.

For instance, ARP is an extremely insecure protocol, and a rogue ARP 
responder can wreak absolute havoc on a network.  A rogue DHCP server 
can also wreak havoc.

But anyway this is the HTTP WG mailing list not the DHC one :)  And 
you've all heard more than enough from me today I'm sure :)

All I'm getting at is that people are making arguments about security of 
configuration, and making assertions about superior suitability of 
protocols such as DHCP and DNS in that same context. 

I would argue that HTTP has much more capability of being much more 
secure over a much broader realm than DNS or DHCP ever will have, and 
that therefore maybe HTTP is a more suitable protocol to be used for 
certain configuration tasks, especially more security-sensitive ones. 

Cheers

Adrien


(*) E.g. signing of emails, SSL certificates etc.  TLS is a special case 
- it's really an application level protocol, sitting as it does over 
TCP.  IPSEC would be the closest I guess to packet level security.  It's 
hideously over-burdened in terms of administration though, which I 
believe has hampered its widespread adoption in LAN operation (apart 
from the obvious performance issues).


Mark Andrews wrote:
>> Mark Andrews wrote:
>>>>     
>>> 	To be perfectly honest.  Applications SHOULD have access to
>>> 	DHCP configuration results. 
>>>
>>>   
>> I wish :)
>>
>> They should also be able to instigate DHCP_INFORM requests to request 
>> specific parameters from the DHCP server as well.
>>
>> I don't see it happening any time soon though
>
> 	Some OS already do this.  As a DHCP vendor (client and server)
> 	improving integration with the rest of the OS is on our roadmap.
>  

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 19 June 2007 07:09:31 UTC