Re: Possible DHCP DOS attack

[sen_ml () ECCOSYS COM (Sen_Ml Sen_Ml)]

Ogrodnek> SOTO.  Please see RFC 2131.  This is being addressed in part
Ogrodnek> in the IETF draft "Authentication for DHCP Messages"
Ogrodnek> <draft-ietf-dhc-authentication-12.txt>.  These documents
Ogrodnek> among others can be found at http://www.dhcp.org.

i looked at:

  http://www.ietf.org/internet-drafts/draft-ietf-dhc-authentication-12.txt

it appears to offer two protocols, 0 and 1.

if i understand the draft correctly, 0 does authentication via shared
secrets in the clear and 1 does authentication via digests (similar to
apop, i think -- hmac-md5).  please tell me if i'm off in a
significant way.

if i am not mistaken, both protocols require plaintext secrets to be
available on the client -- for protocol 0, it's obvious why; for
protocol 1, to compute the digest.

if network initialization is going to happen unattended, it seems
likely that secrets will be stored in the clear on the client.  for
the case of an insider attack, surely it won't be difficult for the
insider to get a hold of a secret on someone else's machine and use
that elsewhere, perhaps along w/ modifying the mac address of the
machine they wish to do mischief via.  well, it'll sure be easy in
windows 9x anyway ;-)  but perhaps not so easy for machines that have
some multiuser concept like un*x or nt.  don't know about macs these
days, anyone>

it seems that some effort will have to be put into securing the
secrets on the client end if you don't trust your users and you don't
want people running off w/ your ip addresses.  if you can live w/
delayed network initialization, perhaps you could store the secrets on
the client in an encrypted form which can be decrypted by a user
typing in a passphrase -- after which dhcp authentication can occur.

note, that this clearly goes beyond merely dhcp.

the distribtion of the shared secrets must be done out-of-band as well
as the draft suggests, which i believe may be significant overhead for
a large site -- very similar to key distribution problems faced by
public key systems, perhaps?

i don't really see how this helps for large sites.  i think the issue
is hard to address, if not impossible, via only extensions to dhcp.

i say everyone just get pgp, store the public keys on the dhcp servers
and we just do challenge-and-response authentication for everything ;-)

please do note the smily.