I don't object to Steve's proposal to clarify the goal and limitations
of the use of md5 in the security considerations section. what we're
trying to achieve in the DHCID rrs is certainly no stronger than the
'privacy' offered by stateless v6 addresses or rfc3041 addresses. we
aren't really making a 'privacy' claim; there's plenty of other
un-obscured information available in the DNS along with the DHCIDs.
we're only trying to make it difficult to track a DHCP client as it
moves from address to address. md5 makes it more difficult than the
plain-text version of an ethernet MAC address; that's "enough" for our
purpose.
would such a clarification be "enough" to resolve your DISCUSS, Sam
Hartman? that is, if it were clearer that we're only aiming for more
difficult than not difficult at all - would that be sufficiently clear
guidance to admins about what they should expect from this mechanism?
-- Mark
Steven M. Bellovin wrote:
In message <[EMAIL PROTECTED]>, 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
___
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
