Re: IPv6 and Dynamic DNS

["Donald E. Eastlake 3rd" <dee3@torque.pothole.com>]

Well, I haven't been paying that close attention to this, but here is
my take.

If a guest machine auto-configures on some net, it will presumably
have a key that gives it authority to update its forward address
record.  This could be a TSIG secret key shared with the primary
server of its forward name zone, but, since this is an infrequent
operation so efficiency is not that important, I would think the
higher security of using a public key and signing the update of the
forward address RR(s) with a SIG is the way to go. Or, of course, you
can just use TKEY to set up a temporary TSIG key securely based on the
public key although this adds at least one round trip.

Now we get to updating the inverse zone.  There is basicly the
non-crypto and the crypo say of going about it.

Non-Crypto is to pretty much trust unsigned local updated based on
indicita like the packet source address, checking against an address
retrieval under the name (would be nice if the forward zone were
secure), and whatever else you can think of.  This just doesn't seem
that bad to me.  While a malicious machine could try to fill up the
inverse zone or something, having a malicious machine on your LAN is
likely to lead to other problems and you should probably have some
background process to delete inverse entries by guest machines that
seem to have disappeared from your net anyway.  Or/and maybe you
should be checing when a PTR is entered in an inverse zone by doing an
inverse query for the name and auto-deleting any PTR for that name
under a different address unless there are actually multiple addresses
under that name in the foward zone.  (But, of course, a malicious
host can easily arrange to have control of zillions of names.)

In the first Crypto way to do it, the inverse zone server could
require that the update by signed by the key for the forward name.
This is pretty much impossible or a severe security risk if you are
just using secret TSIG keys directly.  If the inverse zone server
doesn't know the secret key, it can't veryify the signature.  If it
doesn, suddenly this random server on some net you are visiting can
forge signatures on your behalf.  On the other hand, if you are
building from public keys, TKEY can be used to set up a secret key
with the inverse zone server which only the mobile host and that
server know.  But, if the forward zone is secure, this is not much
better that just checking the forward address records.

The second Crypto way to do it assumes a key that specifically
authorizes update for the local inverse zone is somehow set up on the
mobile host.  This could be a secret TSIG key shared with the inverse
zone server or a public key that is used to directly SIG update or is
used with TKEY to derive a temporary secret key to TSIG update.  This
has the advantage that you no longer need access to the forward zone
or server. But this just begs the question.  What administrative
system is going to be giving this key to a miscellaneous mobile host
that is visiting and on what basis and what is to stop a host from
getting 10 or 10,000 such keys?  If you have a human being do it, that
rate limits you pretty well but is obviously a pain.  You would want
to have some feature where you knew that this inverse update
authorizing key was only good for entering a single inverse entry and
if it tries to enter a second one, the first goes away.  Sometimes
this second crypto way would be better but it seems to me that
whatever administrative system give out this locally authorizing key
could just as well accept and authorize the update itself, sending it
on to the inverse server.  Maybe visitors could be given a smart card
or something with a time limited key...

TKEY does have modes where the client can just send a key to the
server or the server can just send a key to the client, authenticated
by SIGs under the name of the client or server, but this doesn't help
particularly.

I don't believe that GSS-TSIG solves any of this.  It just pushes the
whole thing off on GSS which has the same problem that you can't trust
an unknwon guest mobile host not to act maliciously.

If you are not worried about malicious actions but just want to be
sure it has authority for the name it is putting in the inverse zone,
Crypt method one above should be fine.

Hope I haven't missed so much of the conversation that my comments
are not applicable.

Donald

From:  Paul A Vixie <vixie@mibh.net>
Message-Id:  <199908110223.TAA18189@bb.rc.vix.com>
To:  namedroppers@internic.net
In-reply-to:  Your message of "Tue, 10 Aug 1999 19:17:32 PDT."
	                  <078292D50C98D2118D090008C7E9C6A6017942E9@STAY.platinum.corp.microsoft.com> 
Date:  Tue, 10 Aug 1999 19:23:44 -0700

>> Can't the router update the DNS?
>
>if the router knows when a new address has been assigned with stateless
>autoconf, and if the router knows the "forward name" to be associated with
>the address just assigned, and if the router can know a TSIG shared secret
>or some other private key that protects the in-addr.arpa or ip6.int PTR's,
>then sure.
>
>however, i think we're dealing with a more fundamental problem.  microsoft
>avoided something similar by using GSS TSIG.  what's needed is an opaque
>and somewhat anonymous and short lived permission blob, that's only useful
>for updating one particular thing at one particular time.  TKEY to the
>rescue?  donald, are you still listening, and can you chime in?