Vulnerability Development mailing list archives
Re: Possible DHCP DOS attack
From: sen_ml () ECCOSYS COM (Sen_Ml Sen_Ml)
Date: Fri, 4 Feb 2000 18:15:02 +0900
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.
Current thread:
- Re: how to transfer files on napster, (continued)
- Re: how to transfer files on napster Blue Boar (Feb 05)
- Re: how to transfer files on napster Seth Georgion (Feb 05)
- Re: how to transfer files on napster whitvamp () MINDLESS COM (Feb 05)
- Re: how to transfer files on napster Jordan Ritter (Feb 05)
- Re: how to transfer files on napster Blue Boar (Feb 07)
- Re: how to transfer files on napster David U. (Feb 07)
- Simple logging utility app Scorpus Kahn (Feb 06)
- Re: Simple logging utility app Erik Parker (Feb 07)
- Breaking through FTP ALGs -- is it possible? Mikael Olsson (Feb 08)
- Re: Possible DHCP DOS attack Sen_Ml Sen_Ml (Feb 04)