is TSIG key rollover possible?

[Mark Elkins]

Don't think TSIG Key roll-over is possible - in the DNSSEC sense. Don't
think it is as necessary either. I have separate TSIG relationships
between my Primary and Secondary peers. I use the same TSIG for all
zones that are on both peers - the TSIG is to secure the path between
the two peers. I also have 'ssh' access to the peers and in order to
perform a 'roll-over' would be logged in (ssh) to both sides of a single
pair of peers when doing the update. The job thus would be..

a) change the config files on both sides
b) signal named to reread its config - on both sided

In total - I directly look after just eight such pairs of peers - not
that hard. I change the signatures every 9 months.

The only Gotcha to changing from hmac-md5 to one of the other algorithms
is that when checking AXFR's with 'dig'  you now need to add a third
argument to the '-y' option - the algorithm to use. [-y [hmac:]name:key]

In real life - I run an ISP and offer paid for 'secondary' nameserver
services to my clients (ie those with their own hosted servers). I thus
dress all this up with Web pages and a database backend. TSIG is a free
option - all made nice'n'easy ("change your named.conf to look like
this..." cut-n-paste) even with e-mail reminders to change old
signatures. Almost no one uses the TSIG option - no one seems very
interested. (Hey mark - that's a very cool feature - I'll see if I have
the time to get around to it one day....)

On Wed, 2009-09-16 at 17:08 +1200, Sebastian Castro wrote:
> Hi everyone:
> 
> I was reading the document "Deprecation of HMAC-MD5 in DNS TSIG and TKEY
> Resource Records"
> (http://www.ietf.org/id/draft-ietf-dnsext-tsig-md5-deprecated-03.txt)
> and I thought "Darn, I must be prepared to do a TSIG renovation", so
> started researching how to do it.
> 
> First step was checking if BIND supported a different algorithm, but the
> BIND ARM for BIND9.5 and 9.6 indicates "The algorithm, hmac-md5, is the
> only one supported by BIND". That seemed strange, considering the
> document indicated above was originally proposed in 2008. So I "used the
> source" and found out other algorithms are supported in 9.5 and 9.6, so
> there is a mistake in the documentation.
> 
> Anyway, TSIG rollover is an operation needed as indicated on RFC 2385:
> 
> -------------------- RFC 2385 quote -----------------------------
> 6.2. Secret keys should be changed periodically.  If the client host
>    has been compromised, the server should suspend the use of all
>    secrets known to that client.  If possible, secrets should be stored
>    in encrypted form.  Secrets should never be transmitted in the clear
>    over any network.  This document does not address the issue on how to
>    distribute secrets. Secrets should never be shared by more than two
>    entities.
> -------------------- RFC 2385 quote -----------------------------
> 
> but again the documentation indicates: "Multiple keys may be present,
> but only the first is used."
> 
> So, to coordinate the retirement of an old TSIG key and the introduction
> of a new one, it seems a close coordination between peers is needed in
> order to make it work, within a 'maintenance window' where the
> operations using the TSIG are not executed (in my particular interest,
> zone transfers)? Is it not possible to gradually introduce a new key,
> use both for a period of time and later retire the old one, similar to
> what is done in DNSSEC?
> 
> Any experience on this matter that could be shared publicly or privately
> will be appreciated.
> 
> Kind Regards
> Sebastian Castro
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
  .  .     ___. .__      Posix Systems - Sth Africa.  e.164 VOIP ready
 /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496