BTW, whatever algorithm you use (SHA-256 or even something much more
complex) is not going to help -- it may make the work someone has to do
a bit more involved, but it really doesn't make it impossible.
1. You always have a brute force attack. As you indicate, calculating
the hash based on the mac address is always going to be a possible
attack. And, 8000 is not 8-bits, but more like 13. But agreed that many
of the Ethernet OIDs are unlikely to be of much interest.
2. If the attacker is on the same network as the client at some point,
they can learn the identifier of the client (snoop DHCP and/or ARP
traffic). Once they have that, it is possible to query DNS for DHCID RRs
(query for the PTR, query for a DHCID RR for the name). Once you have
that, you use the name and client's identity and run it through the
algorithm and check for a match. If you looked up all 2^32 PTRs, you'd
be able to locate the client at other sites that use DHCP and export the
DHCID RR information. The number of PTRs you'd likely have to query is
much smaller than 2^32s.
You could target just some domains (network addresses) that you were
most interested in or where you suspect the client connects to the
network. Far reducing the number of queries needed.
- Bernie
-----Original Message-----
From: dhcwg-bounces(_at_)ietf(_dot_)org
[mailto:dhcwg-bounces(_at_)ietf(_dot_)org]
On Behalf Of Steven M. Bellovin
Sent: Monday, November 28, 2005 11:49 AM
To: Ted Lemon
Cc: iesg(_at_)ietf(_dot_)org; dhcwg(_at_)ietf(_dot_)org;
namedroppers(_at_)ops(_dot_)ietf(_dot_)org;
Pekka Savola; ietf(_at_)ietf(_dot_)org
Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:
'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed
Standard]
In message <200511261243(_dot_)21694(_dot_)mellon(_at_)fugue(_dot_)com>, Ted
Lemon writes:
Making a hash function interchangeable in DHCID makes the
conflict detection
algorithm hugely more complicated, and possibly not workable
at all. Think
about how that would work.
I confess that I don't see the problem. The updater would do a DNS
query for DHCID RRs; it would be given all of the stored
records. The
updater would then use local policy -- that is, an ordered list of
preferred hash functions -- until it found one that was in the
response. That one would be used. If no locally-known hash
functions
are in the list, it should behave as if there were no DHCID records
present for that name. DNSSEC could protect against
downgrade attacks.
(Speaking of which -- were I still AD, I'd ding this document for an
inadequate Security Considerations section -- apart from the
lack of discussion of brute force attacks, you should cite
3833 for DNS
attacks and explain what the risks are if someone can crack the hash
function by any means, including brute force or eavesdropping on the
wire or (perhaps) a misbehaving updater.)
If you don't agree, I'd strongly suggest using SHA-256
instead of MD5.
Yes, it's more expensive, but I doubt that that's a major hit on
overall system performance here. It would also be useful to
include in
the document some discussion of upgrade strategy -- how would we ever
switch to a new hash function? That's non-trivial even for protocols
designed for agility, as Eric Rescorla and I have shown. No
matter how
it's done, this one is among the very hardest, since DNS
servers would
have to supply DHCID records for several hashes for a number of years.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
dhcwg mailing list
dhcwg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf