Re: is TSIG key rollover possible?

2009-09-16 Thread 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@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?

2009-09-16 Thread 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@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?

2009-09-15 Thread Mark Andrews

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