Re: is TSIG key rollover possible?
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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- . . ___. .__ Posix Systems - Sth Africa. e.164 VOIP ready /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: is TSIG key rollover possible?
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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: is TSIG key rollover possible?
In message 4ab072dc.2070...@nzrs.net.nz, Sebastian Castro writes: 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. Which only applies to control channels keys. 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users