Re: [Mip6] Re: RFC2136 and IP address ownership

[Mark Andrews <Mark_Andrews@isc.org>]

> # > i'd say that key compromise is out of scope for RFC 2136 or any technology
> # > based on it.  a simple caveat, "by the way, if the key is compromised,
> # > then all bets are off," is all anyone could expect.
> # 
> # Key compromise wasn't what I was talking about.  The case is an end node
> # with a perfectly legitimate key that decides to launch a redirection attack.
> # The attack could be deliberate, for example, a user with a legitimate
> # account establishes a security association but launches the attack for some
> # reason (for example, the victim is an ex-spouse in the middle of a contested
> # divorce proceeding and the attacker wants to harrass him/her), or it could
> # be inadvertent, for example, the end node is infected with a virus or
> # spyware.  I think only the latter could be considered a key compromise.
> 
> i think i got your meaning the second time here.  basically you're saying that
> the "self" ACL, with whatever tricks needed to work with RFC 2317, is still
> nec'y because otherwise we'll have to protect individual DNS names with unique
> keys per host, which won't scale.

	For RFC 2317 style zones I suspect they will need to know the prefix
	and range by some out of band mechanism and how the non prefix bits
	map into the owner-name.

	Off the top of my head this would be how I would implement it for
	BIND.

	e.g.
	allow-update {
		self 1.2.3.128 1.2.3.200 "${4}.128-200.3.2.1.in-addr.arpa";
	};

	And the general case for the non RFC 2317 style reverse zone.

	allow-update {
		self 0.0.0.0 255.255.255.255 "${4}.${3}.${2}.${1}.in-addr.arpa";
	};

>  hmmmm.  i wonder how microsoft's GSS-TSIG
> works around this?  (possibly by just outlawing RFC 2317 for ancestor zones,
> or by requiring a certain label syntax rather than leaving it to user choice?)

 
> i agree that the security considerations section of any resulting specification
> ought to have words to the effect that "in no case should an end-node have the
> ability to update DNS names nearby but not equal to those needed for its own
> IN-ADDR registrations".
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>