is TSIG key rollover possible?

[Sebastian Castro]

Mark Elkins wrote:
> 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.

Thanks for sharing your experience. In my particular case, I 'own' part
of the set of nameservers for my zones and the rest is provided by
external DNS providers. When you have full control of your machines, you
can prepare this change without issues: you change the keys, check the
conf files, push the new files and reload everything. But when you have
third parties involved in different time zones, is more complicated to
coordinate a time to do the same task.

I will investigate more based on Mark Andrews' reply and let the list know.

cheers
Sebastian Castro

> 
> 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