In message <200511282150.01493.Ted.Lemon@xxxxxxxxxxx>, 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf