In message
<200511282150(_dot_)01493(_dot_)Ted(_dot_)Lemon(_at_)nominum(_dot_)com>, Ted
Lemon writes:
On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote:
In fact, the Security Considerations section should analyze the
(non-trivial) probability of a brute-force attack.
It doesn't matter. The point of the DHCID is to allow two servers to avoid
accidentally stepping on each other. If you break the DHCID, what you get
is the ability to pretend that you are another DHCP client. If you succeed
in doing this, you can take over that DHCP client's name, but you don't get
to keep it, because you are using the same identification as the other
client, and so it's going to take it back. The information that you would
use to pretend to be the other client is routinely being sent over the
network in the clear, so you don't need to break the DHCID to get it - you
just need to listen on the wire for a packet from that client. You can't do
the attack I've described unless you are on a network managed by a DHCP
server that manages the same namespace as the server that put in the
legitimate DHCID.
It's true that we could exhaustively go over all possible exploits, no matter
how trivial, no matter how useless, in the security considerations section.
Do you honestly believe that this is necessary?
It's the privacy aspect I'm concerned about. The protocol has a
mechanism -- the hash -- intended to protect privacy. There are
limitations to how well it works. These may be unavoidable; that said,
they should be documented. See Section 5 of RFC 3552, a BCP:
Authors MUST describe
1. which attacks are out of scope (and why!)
2. which attacks are in-scope
2.1 and the protocol is susceptible to
2.2 and the protocol protects against
...
There should be a clear description of the residual risk to the user
or operator of that protocol after threat mitigation has been
deployed.
Put another way, against a certain grade of attacker the mechanism
doesn't do its job. That needs to be documented, so that people who
are concerned about the issue know to avoid this option.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf