Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On 9.8.2013 16:22, Petr Spacek wrote: On 9.8.2013 15:12, Rob Crittenden wrote: Simo Sorce wrote: On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: On 23.7.2013 10:55, Petr Spacek wrote: On 19.7.2013 19:55, Simo Sorce wrote: I will reply to the rest of the message later if necessary, still digesting some of your answers, but I wanted to address the following first. On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: The most important question at the moment is "What can we postpone? How fragile it can be for shipping it as part of Fedora 20?" Could we declare DNSSEC support as "technology preview"/"don't use it for anything serious"? Until we figur out proper management in LDAP we will be a bit stuck, esp if we want to consider usin the 'somthing' that stores keys instead of toring them stright in LDAP. So maybe we can start with allowing just one server to do DNSSEC and source keys from files for now ? The problem is that DNSSEC deployment *on single domain* is 'all or nothing': All DNS servers have to support DNSSEC otherwise the validation on client side can fail randomly. Note that *parent* zone indicates that the particular child zone is secured with DNSSEC by sending DS (delegation signer) record to the client. Validation will fail if client receives DS record from the parent but no signatures are present in data from 'child' zone itself. This prevents downgrade (DNSSEC => plain DNS) attacks. As a result, we have only two options: One DNS server with DNSSEC enabled or arbitrary number DNS servers without DNSSEC, which is very unfortunate. as soon as we have that workign we should also have clearer plans about how we manage keys in LDAP (or elsewhere). Dmitri, Martin and me discussed this proposal in person and the new plan is: - Elect one super-master which will handle key generation (as we do with special CA certificates) I guess we can start this way, but how do you determine which one is master ? How do we select the 'super-master' for CA certificates? I would re-use the same logic (for now). I do not really like to have all this 'super roles', it's brittle and admins will be confused which means one day their whole infrastructure will be down because the keys are expired and all the clients will refuse to communicate with anything. AFAIU keys don't expire, rather there is a rollover process. The problem would be if the server that controlled the rollover went away the keys would never roll, leaving you potentially exposed. In DNSSEC it could be a problem. Each signature contains validity interval and validation will fail when it expires. It practically means that DNS will stop working if the keys are not rotated in time. (More keys can co-exists, so the roll-over process can be started e.g. a month before the current key really expires.) I think it is ok as a first implementation, but I think this *must not* be the final state. We can and must do better than this. I definitely agree. IMHO the basic problem is the same or very similar for DNSSEC key generation & CA certificates, so we should solve both problems at once - one day. I mean - we need to coordinate key & cert maintenance between multiple masters somehow - and this will be the common problem for CA & DNSSEC. - Store generated DNSSEC keys in LDAP - Encrypt stored keys with 'DNSSEC master key' shared by all servers ok. - Derive 'DNSSEC master key' from 'Kerberos master key' during server install/upgrade and store it somewhere on the filesystem (as the Kerberos master key, on each IPA server) The Kerberos master key is not stored on disk, furthermore it could change, so if you derive it at install time and install a replica after Interesting. The master key is stored in the krbMKey attribute in cn=REALM,cn=kerberos,dc=your,dc=domain , I didn't know that. it was changed everything will break. I think we need to store the key in LDAP, encrypted, and dump it to disk when a new one is generated. I agree. Aside, DNSSEC uses pub/private key crypto so this would be a special 'master key' used exclusively to encrypt keys in LDAP ? That was the original intention - generate a new 'DNSSEC master key'/'DNSSEC wrapping key' and let named+certmonger/oddjob to play with it. - Consider certmonger or oddjob as key generation triggers I do not understand this comment. I mean: How hard would it be to extend certmonger/oddjob to take care of DNSSEC key maintenance? He is trying to automate the key rollover. I don't think certmonger will work as it is designed for X.509 certs. Are you proposing an additional attribute to schedule the rollover? I thought that it was a good idea to have some flexibility here to prevent timed DoS attacks for rollover time. It definitely requires some changes in certmonger, I'm just exploring various possibilities. I think that we should add one new thing - a 'salt' - used for Kerberos master key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On 12.8.2013 14:30, Loris Santamaria wrote: El vie, 09-08-2013 a las 16:22 +0200, Petr Spacek escribió: On 9.8.2013 15:12, Rob Crittenden wrote: Simo Sorce wrote: On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: On 23.7.2013 10:55, Petr Spacek wrote: On 19.7.2013 19:55, Simo Sorce wrote: I will reply to the rest of the message later if necessary, still digesting some of your answers, but I wanted to address the following first. On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: The most important question at the moment is "What can we postpone? How fragile it can be for shipping it as part of Fedora 20?" Could we declare DNSSEC support as "technology preview"/"don't use it for anything serious"? Until we figur out proper management in LDAP we will be a bit stuck, esp if we want to consider usin the 'somthing' that stores keys instead of toring them stright in LDAP. So maybe we can start with allowing just one server to do DNSSEC and source keys from files for now ? The problem is that DNSSEC deployment *on single domain* is 'all or nothing': All DNS servers have to support DNSSEC otherwise the validation on client side can fail randomly. Note that *parent* zone indicates that the particular child zone is secured with DNSSEC by sending DS (delegation signer) record to the client. Validation will fail if client receives DS record from the parent but no signatures are present in data from 'child' zone itself. This prevents downgrade (DNSSEC => plain DNS) attacks. As a result, we have only two options: One DNS server with DNSSEC enabled or arbitrary number DNS servers without DNSSEC, which is very unfortunate. as soon as we have that workign we should also have clearer plans about how we manage keys in LDAP (or elsewhere). Dmitri, Martin and me discussed this proposal in person and the new plan is: - Elect one super-master which will handle key generation (as we do with special CA certificates) I guess we can start this way, but how do you determine which one is master ? How do we select the 'super-master' for CA certificates? I would re-use the same logic (for now). I do not really like to have all this 'super roles', it's brittle and admins will be confused which means one day their whole infrastructure will be down because the keys are expired and all the clients will refuse to communicate with anything. AFAIU keys don't expire, rather there is a rollover process. The problem would be if the server that controlled the rollover went away the keys would never roll, leaving you potentially exposed. In DNSSEC it could be a problem. Each signature contains validity interval and validation will fail when it expires. It practically means that DNS will stop working if the keys are not rotated in time. (More keys can co-exists, so the roll-over process can be started e.g. a month before the current key really expires.) I think it is ok as a first implementation, but I think this *must not* be the final state. We can and must do better than this. I definitely agree. IMHO the basic problem is the same or very similar for DNSSEC key generation & CA certificates, so we should solve both problems at once - one day. I mean - we need to coordinate key & cert maintenance between multiple masters somehow - and this will be the common problem for CA & DNSSEC. You could implement a "protocol" where each master has a day or the week or the month where it checks if there are any pending keys or CA certificates to renew and tries to do the job. Next day it is another master's turn to do the same job and so on. Every master is identified by an unique nsDS5ReplicaId, which could be used as a vector to generate an ordered list of masters. If you have masters with nsDS5ReplicaId 5,34,35,45 you can say that the one with nsDS5ReplicaId 5 is master number one, the next is master number two and so on. On first day of the month it is master number one's turn to check of any pending key and CA certificate renewal issues and to do the renewal. On second day of the month it is master number two's turn to do the same. So if a master was down the job will be done next day by the next master. The cicle will repeat every "number of master" days, in the example every four days. It is interesting idea... but I think that it is could be fragile and create some serious problems. Please see and reply to e-mail in this thread: https://www.redhat.com/archives/freeipa-devel/2013-September/msg00015.html Thank you for your time & contribution! -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On Monday, August 12, 2013 09:34:19 AM Martin Kosek wrote: > On 08/09/2013 04:13 PM, Anthony Messina wrote: > > On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote: > >>> Dmitri, Martin and me discussed this proposal in person and the new > >>> plan is: - Elect one super-master which will handle key generation (as > >>> we do with special CA certificates) > >> > >> > >> > >> I guess we can start this way, but how do you determine which one is > >> master ? I do not really like to have all this 'super roles', it's > >> brittle and admins will be confused which means one day their whole > >> infrastructure will be down because the keys are expired and all the > >> clients will refuse to communicate with anything. > >> > >> > >> > >> I think it is ok as a first implementation, but I think this *must not* > >> be the final state. We can and must do better than this. > > > > > > > > I've been "listening in" on the DNSSEC discussion and do not mean to > > derail the course of this thread, however... > > > > > > > >> From a sysadmin's perspective, I agree with Simo's comments insofar as > >> they > > > > relate to "not all masters being created equal". Administratively, > > unequal masters have the potential to create single points of failure > > which may be difficult to resolve, especially on upgrade between minor > > versions and between replicas. > > > > > > > > Small-time sysadmins like myself who may only run one (maybe two) FreeIPA > > > > instances incur a significant about of trouble when that already limited > > resource isn't working properly after some issue with file ownership or > > > > SELinux during a yum upgrade. > > > > > > > > In addition, I realize FreeIPA wasn't probably designed with small-ish > > installs as the target use case. But I would argue that since FreeIPA > > *is* so unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it > > is a viable choice for small-timers (with the only exception being no real > > way to "back up" an instance without an "always-on" multi-master > > replica). > > > > > > > > As a user who has just completed a "manual" migration/upgrade to F19 > > (after realizing that there really was no way to migrate/upgrade when the > > original install began on F17 2.1 on bare metal with the split slapd > > processes and Dogtag 9, through F18, to F19), I would like to see FreeIPA > > move forward but continue to deliver the above-mentioned services to the > > small-timers, who, without FreeIPA's unification, would never be able to > > manage or offer all of those services independently, like the big-timers > > might be able to. > > > > > > > > Thanks. -A > > Hello Anthony, > > From your post above, I did not understand what is the actual problem with > FreeIPA vs. small-time admins. I personally think that FreeIPA is usable for > both small-timers and bigger deployments (sorry for having to undergo the > manual migration procedure). > > If you see that this is not true in some part of FreeIPA, please comment or > file tickets/RFEs/Bugzillas which we can process and act on to amend the > situation. > > Thanks in advance, > Martin Martin, I *do* think FreeIPA is an excellent choice for small-time admins, especially with the increased effort on improving documentation, the upcoming ipa-client-advise tool, and the ipa-backup/restore tools. I merely wanted to state that 1) I agreed with Simo's comments, and point out that 2) unequal masters with regard to DNSSEC has the potential to be a single point of failure and an area of concern for small-time admins who may for example, already be coping with the, albeit solid, recommendations to run multiple concurrent masters in virtualized environments with duplicates of those environments available simply for testing upgrades (a fair amount of administrative overhead for a small-timer). In short, I was voicing a sysadmin's opinion that FreeIPA should continue to evolve in a way that supports small-time admins as well. I do not think there is a problem with "FreeIPA vs. small-time admins" and am hoping it stays that way. As far as the manual migration... This was likely an issue with documentation and/or release notes: 2.2 said it was ok to upgrade from 2.1, 3.0 said it was ok to upgrade from 2.2, etc. This is likely all true, unless your original 2.2 was based on a 2.1 with Dogtag9. At that point in time, I had one FreeIPA master on bare metal. I have since upgraded my infrastructure and "started over" to have two FreeIPA masters in VMs hosted on separate machines. Hopefully, this amount of redundancy will afford me some upgrade protection for the future. Thanks again. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com http
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
El vie, 09-08-2013 a las 16:22 +0200, Petr Spacek escribió: > On 9.8.2013 15:12, Rob Crittenden wrote: > > Simo Sorce wrote: > >> On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: > >>> On 23.7.2013 10:55, Petr Spacek wrote: > On 19.7.2013 19:55, Simo Sorce wrote: > > I will reply to the rest of the message later if necessary, still > > digesting some of your answers, but I wanted to address the following > > first. > > > > On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: > >> > >> The most important question at the moment is "What can we postpone? > >> How > >> fragile it can be for shipping it as part of Fedora 20?" Could we > >> declare > >> DNSSEC support as "technology preview"/"don't use it for anything > >> serious"? > > > > Until we figur out proper management in LDAP we will be a bit stuck, esp > > if we want to consider usin the 'somthing' that stores keys instead of > > toring them stright in LDAP. > > > > So maybe we can start with allowing just one server to do DNSSEC and > > source keys from files for now ? > > The problem is that DNSSEC deployment *on single domain* is 'all or > nothing': > All DNS servers have to support DNSSEC otherwise the validation on client > side > can fail randomly. > > Note that *parent* zone indicates that the particular child zone is > secured > with DNSSEC by sending DS (delegation signer) record to the client. > Validation > will fail if client receives DS record from the parent but no signatures > are > present in data from 'child' zone itself. > > This prevents downgrade (DNSSEC => plain DNS) attacks. > > As a result, we have only two options: One DNS server with DNSSEC > enabled or > arbitrary number DNS servers without DNSSEC, which is very unfortunate. > > > as soon as we have that workign we should also have clearer plans about > > how we manage keys in LDAP (or elsewhere). > >>> > >>> Dmitri, Martin and me discussed this proposal in person and the new plan > >>> is: > >>> - Elect one super-master which will handle key generation (as we do with > >>> special CA certificates) > >> > >> I guess we can start this way, but how do you determine which one is > >> master ? > How do we select the 'super-master' for CA certificates? I would re-use the > same logic (for now). > > >> I do not really like to have all this 'super roles', it's brittle and > >> admins will be confused which means one day their whole infrastructure > >> will be down because the keys are expired and all the clients will > >> refuse to communicate with anything. > > > > AFAIU keys don't expire, rather there is a rollover process. The problem > > would > > be if the server that controlled the rollover went away the keys would never > > roll, leaving you potentially exposed. > In DNSSEC it could be a problem. Each signature contains validity interval > and > validation will fail when it expires. It practically means that DNS will stop > working if the keys are not rotated in time. (More keys can co-exists, so the > roll-over process can be started e.g. a month before the current key really > expires.) > > >> I think it is ok as a first implementation, but I think this *must not* > >> be the final state. We can and must do better than this. > I definitely agree. IMHO the basic problem is the same or very similar for > DNSSEC key generation & CA certificates, so we should solve both problems at > once - one day. > > I mean - we need to coordinate key & cert maintenance between multiple > masters > somehow - and this will be the common problem for CA & DNSSEC. You could implement a "protocol" where each master has a day or the week or the month where it checks if there are any pending keys or CA certificates to renew and tries to do the job. Next day it is another master's turn to do the same job and so on. Every master is identified by an unique nsDS5ReplicaId, which could be used as a vector to generate an ordered list of masters. If you have masters with nsDS5ReplicaId 5,34,35,45 you can say that the one with nsDS5ReplicaId 5 is master number one, the next is master number two and so on. On first day of the month it is master number one's turn to check of any pending key and CA certificate renewal issues and to do the renewal. On second day of the month it is master number two's turn to do the same. So if a master was down the job will be done next day by the next master. The cicle will repeat every "number of master" days, in the example every four days. -- Loris Santamaria linux user #70506 xmpp:lo...@lgs.com.ve Links Global Services, C.A.http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:1...@lgs.com.ve "If I'd asked my customers what they wanted, they'd have said a faste
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On 08/09/2013 04:13 PM, Anthony Messina wrote: > On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote: >>> Dmitri, Martin and me discussed this proposal in person and the new >>> plan is: - Elect one super-master which will handle key generation (as >>> we do with special CA certificates) >> >> I guess we can start this way, but how do you determine which one is >> master ? I do not really like to have all this 'super roles', it's >> brittle and admins will be confused which means one day their whole >> infrastructure will be down because the keys are expired and all the >> clients will refuse to communicate with anything. >> >> I think it is ok as a first implementation, but I think this *must not* >> be the final state. We can and must do better than this. > > I've been "listening in" on the DNSSEC discussion and do not mean to > derail the course of this thread, however... > >> From a sysadmin's perspective, I agree with Simo's comments insofar as >> they > relate to "not all masters being created equal". Administratively, > unequal masters have the potential to create single points of failure > which may be difficult to resolve, especially on upgrade between minor > versions and between replicas. > > Small-time sysadmins like myself who may only run one (maybe two) FreeIPA > instances incur a significant about of trouble when that already limited > resource isn't working properly after some issue with file ownership or > SELinux during a yum upgrade. > > In addition, I realize FreeIPA wasn't probably designed with small-ish > installs as the target use case. But I would argue that since FreeIPA > *is* so unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it > is a viable choice for small-timers (with the only exception being no real > way to "back up" an instance without an "always-on" multi-master > replica). > > As a user who has just completed a "manual" migration/upgrade to F19 > (after realizing that there really was no way to migrate/upgrade when the > original install began on F17 2.1 on bare metal with the split slapd > processes and Dogtag 9, through F18, to F19), I would like to see FreeIPA > move forward but continue to deliver the above-mentioned services to the > small-timers, who, without FreeIPA's unification, would never be able to > manage or offer all of those services independently, like the big-timers > might be able to. > > Thanks. -A Hello Anthony, >From your post above, I did not understand what is the actual problem with FreeIPA vs. small-time admins. I personally think that FreeIPA is usable for both small-timers and bigger deployments (sorry for having to undergo the manual migration procedure). If you see that this is not true in some part of FreeIPA, please comment or file tickets/RFEs/Bugzillas which we can process and act on to amend the situation. Thanks in advance, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On 9.8.2013 15:12, Rob Crittenden wrote: Simo Sorce wrote: On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: On 23.7.2013 10:55, Petr Spacek wrote: On 19.7.2013 19:55, Simo Sorce wrote: I will reply to the rest of the message later if necessary, still digesting some of your answers, but I wanted to address the following first. On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: The most important question at the moment is "What can we postpone? How fragile it can be for shipping it as part of Fedora 20?" Could we declare DNSSEC support as "technology preview"/"don't use it for anything serious"? Until we figur out proper management in LDAP we will be a bit stuck, esp if we want to consider usin the 'somthing' that stores keys instead of toring them stright in LDAP. So maybe we can start with allowing just one server to do DNSSEC and source keys from files for now ? The problem is that DNSSEC deployment *on single domain* is 'all or nothing': All DNS servers have to support DNSSEC otherwise the validation on client side can fail randomly. Note that *parent* zone indicates that the particular child zone is secured with DNSSEC by sending DS (delegation signer) record to the client. Validation will fail if client receives DS record from the parent but no signatures are present in data from 'child' zone itself. This prevents downgrade (DNSSEC => plain DNS) attacks. As a result, we have only two options: One DNS server with DNSSEC enabled or arbitrary number DNS servers without DNSSEC, which is very unfortunate. as soon as we have that workign we should also have clearer plans about how we manage keys in LDAP (or elsewhere). Dmitri, Martin and me discussed this proposal in person and the new plan is: - Elect one super-master which will handle key generation (as we do with special CA certificates) I guess we can start this way, but how do you determine which one is master ? How do we select the 'super-master' for CA certificates? I would re-use the same logic (for now). I do not really like to have all this 'super roles', it's brittle and admins will be confused which means one day their whole infrastructure will be down because the keys are expired and all the clients will refuse to communicate with anything. AFAIU keys don't expire, rather there is a rollover process. The problem would be if the server that controlled the rollover went away the keys would never roll, leaving you potentially exposed. In DNSSEC it could be a problem. Each signature contains validity interval and validation will fail when it expires. It practically means that DNS will stop working if the keys are not rotated in time. (More keys can co-exists, so the roll-over process can be started e.g. a month before the current key really expires.) I think it is ok as a first implementation, but I think this *must not* be the final state. We can and must do better than this. I definitely agree. IMHO the basic problem is the same or very similar for DNSSEC key generation & CA certificates, so we should solve both problems at once - one day. I mean - we need to coordinate key & cert maintenance between multiple masters somehow - and this will be the common problem for CA & DNSSEC. - Store generated DNSSEC keys in LDAP - Encrypt stored keys with 'DNSSEC master key' shared by all servers ok. - Derive 'DNSSEC master key' from 'Kerberos master key' during server install/upgrade and store it somewhere on the filesystem (as the Kerberos master key, on each IPA server) The Kerberos master key is not stored on disk, furthermore it could change, so if you derive it at install time and install a replica after Interesting. The master key is stored in the krbMKey attribute in cn=REALM,cn=kerberos,dc=your,dc=domain , I didn't know that. it was changed everything will break. I think we need to store the key in LDAP, encrypted, and dump it to disk when a new one is generated. I agree. Aside, DNSSEC uses pub/private key crypto so this would be a special 'master key' used exclusively to encrypt keys in LDAP ? That was the original intention - generate a new 'DNSSEC master key'/'DNSSEC wrapping key' and let named+certmonger/oddjob to play with it. - Consider certmonger or oddjob as key generation triggers I do not understand this comment. I mean: How hard would it be to extend certmonger/oddjob to take care of DNSSEC key maintenance? He is trying to automate the key rollover. I don't think certmonger will work as it is designed for X.509 certs. Are you proposing an additional attribute to schedule the rollover? I thought that it was a good idea to have some flexibility here to prevent timed DoS attacks for rollover time. It definitely requires some changes in certmonger, I'm just exploring various possibilities. I think that we should add one new thing - a 'salt' - used for Kerberos master key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC master key as necessary wi
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote: > > Dmitri, Martin and me discussed this proposal in person and the new plan > > is: - Elect one super-master which will handle key generation (as we do > > with special CA certificates) > > I guess we can start this way, but how do you determine which one is > master ? > I do not really like to have all this 'super roles', it's brittle and > admins will be confused which means one day their whole infrastructure > will be down because the keys are expired and all the clients will > refuse to communicate with anything. > > I think it is ok as a first implementation, but I think this *must not* > be the final state. We can and must do better than this. I've been "listening in" on the DNSSEC discussion and do not mean to derail the course of this thread, however... >From a sysadmin's perspective, I agree with Simo's comments insofar as they relate to "not all masters being created equal". Administratively, unequal masters have the potential to create single points of failure which may be difficult to resolve, especially on upgrade between minor versions and between replicas. Small-time sysadmins like myself who may only run one (maybe two) FreeIPA instances incur a significant about of trouble when that already limited resource isn't working properly after some issue with file ownership or SELinux during a yum upgrade. In addition, I realize FreeIPA wasn't probably designed with small-ish installs as the target use case. But I would argue that since FreeIPA *is* so unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it is a viable choice for small-timers (with the only exception being no real way to "back up" an instance without an "always-on" multi-master replica). As a user who has just completed a "manual" migration/upgrade to F19 (after realizing that there really was no way to migrate/upgrade when the original install began on F17 2.1 on bare metal with the split slapd processes and Dogtag 9, through F18, to F19), I would like to see FreeIPA move forward but continue to deliver the above-mentioned services to the small-timers, who, without FreeIPA's unification, would never be able to manage or offer all of those services independently, like the big-timers might be able to. Thanks. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
Simo Sorce wrote: On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: On 23.7.2013 10:55, Petr Spacek wrote: On 19.7.2013 19:55, Simo Sorce wrote: I will reply to the rest of the message later if necessary, still digesting some of your answers, but I wanted to address the following first. On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: The most important question at the moment is "What can we postpone? How fragile it can be for shipping it as part of Fedora 20?" Could we declare DNSSEC support as "technology preview"/"don't use it for anything serious"? Until we figur out proper management in LDAP we will be a bit stuck, esp if we want to consider usin the 'somthing' that stores keys instead of toring them stright in LDAP. So maybe we can start with allowing just one server to do DNSSEC and source keys from files for now ? The problem is that DNSSEC deployment *on single domain* is 'all or nothing': All DNS servers have to support DNSSEC otherwise the validation on client side can fail randomly. Note that *parent* zone indicates that the particular child zone is secured with DNSSEC by sending DS (delegation signer) record to the client. Validation will fail if client receives DS record from the parent but no signatures are present in data from 'child' zone itself. This prevents downgrade (DNSSEC => plain DNS) attacks. As a result, we have only two options: One DNS server with DNSSEC enabled or arbitrary number DNS servers without DNSSEC, which is very unfortunate. as soon as we have that workign we should also have clearer plans about how we manage keys in LDAP (or elsewhere). Dmitri, Martin and me discussed this proposal in person and the new plan is: - Elect one super-master which will handle key generation (as we do with special CA certificates) I guess we can start this way, but how do you determine which one is master ? I do not really like to have all this 'super roles', it's brittle and admins will be confused which means one day their whole infrastructure will be down because the keys are expired and all the clients will refuse to communicate with anything. AFAIU keys don't expire, rather there is a rollover process. The problem would be if the server that controlled the rollover went away the keys would never roll, leaving you potentially exposed. I think it is ok as a first implementation, but I think this *must not* be the final state. We can and must do better than this. - Store generated DNSSEC keys in LDAP - Encrypt stored keys with 'DNSSEC master key' shared by all servers ok. - Derive 'DNSSEC master key' from 'Kerberos master key' during server install/upgrade and store it somewhere on the filesystem (as the Kerberos master key, on each IPA server) The Kerberos master key is not stored on disk, furthermore it could change, so if you derive it at install time and install a replica after it was changed everything will break. I think we need to store the key in LDAP, encrypted, and dump it to disk when a new one is generated. Aside, DNSSEC uses pub/private key crypto so this would be a special 'master key' used exclusively to encrypt keys in LDAP ? - Consider certmonger or oddjob as key generation triggers I do not understand this comment. He is trying to automate the key rollover. I don't think certmonger will work as it is designed for X.509 certs. Are you proposing an additional attribute to schedule the rollover? I thought that it was a good idea to have some flexibility here to prevent timed DoS attacks for rollover time. I think that we should add one new thing - a 'salt' - used for Kerberos master key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC master key as necessary without a change in the Kerberos master key. Salts are not necessary, HKDF from a cryptographically random key does not require it. Does it make sense? Does anybody have any ideas/recommendations which libraries we should use for key derivation and key material en/decryption? openssl/nss I already have all the basic code we need for that. I prefer the procedure just outlined in https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html which just calls dnssec-keygen rather than trying to roll your own. I don't know what derivation really buys you. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: > On 23.7.2013 10:55, Petr Spacek wrote: > > On 19.7.2013 19:55, Simo Sorce wrote: > >> I will reply to the rest of the message later if necessary, still > >> digesting some of your answers, but I wanted to address the following > >> first. > >> > >> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: > >>> > >>> The most important question at the moment is "What can we postpone? > >>> How > >>> fragile it can be for shipping it as part of Fedora 20?" Could we > >>> declare > >>> DNSSEC support as "technology preview"/"don't use it for anything > >>> serious"? > >> > >> Until we figur out proper management in LDAP we will be a bit stuck, esp > >> if we want to consider usin the 'somthing' that stores keys instead of > >> toring them stright in LDAP. > >> > >> So maybe we can start with allowing just one server to do DNSSEC and > >> source keys from files for now ? > > > > The problem is that DNSSEC deployment *on single domain* is 'all or > > nothing': > > All DNS servers have to support DNSSEC otherwise the validation on client > > side > > can fail randomly. > > > > Note that *parent* zone indicates that the particular child zone is secured > > with DNSSEC by sending DS (delegation signer) record to the client. > > Validation > > will fail if client receives DS record from the parent but no signatures are > > present in data from 'child' zone itself. > > > > This prevents downgrade (DNSSEC => plain DNS) attacks. > > > > As a result, we have only two options: One DNS server with DNSSEC enabled or > > arbitrary number DNS servers without DNSSEC, which is very unfortunate. > > > >> as soon as we have that workign we should also have clearer plans about > >> how we manage keys in LDAP (or elsewhere). > > Dmitri, Martin and me discussed this proposal in person and the new plan is: > - Elect one super-master which will handle key generation (as we do with > special CA certificates) I guess we can start this way, but how do you determine which one is master ? I do not really like to have all this 'super roles', it's brittle and admins will be confused which means one day their whole infrastructure will be down because the keys are expired and all the clients will refuse to communicate with anything. I think it is ok as a first implementation, but I think this *must not* be the final state. We can and must do better than this. > - Store generated DNSSEC keys in LDAP > - Encrypt stored keys with 'DNSSEC master key' shared by all servers ok. > - Derive 'DNSSEC master key' from 'Kerberos master key' during server > install/upgrade and store it somewhere on the filesystem (as the Kerberos > master key, on each IPA server) The Kerberos master key is not stored on disk, furthermore it could change, so if you derive it at install time and install a replica after it was changed everything will break. I think we need to store the key in LDAP, encrypted, and dump it to disk when a new one is generated. Aside, DNSSEC uses pub/private key crypto so this would be a special 'master key' used exclusively to encrypt keys in LDAP ? > - Consider certmonger or oddjob as key generation triggers I do not understand this comment. > I think that we should add one new thing - a 'salt' - used for Kerberos > master > key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC > master key as necessary without a change in the Kerberos master key. Salts are not necessary, HKDF from a cryptographically random key does not require it. > Does it make sense? Does anybody have any ideas/recommendations which > libraries we should use for key derivation and key material en/decryption? openssl/nss I already have all the basic code we need for that. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On 23.7.2013 10:55, Petr Spacek wrote: On 19.7.2013 19:55, Simo Sorce wrote: I will reply to the rest of the message later if necessary, still digesting some of your answers, but I wanted to address the following first. On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: The most important question at the moment is "What can we postpone? How fragile it can be for shipping it as part of Fedora 20?" Could we declare DNSSEC support as "technology preview"/"don't use it for anything serious"? Until we figur out proper management in LDAP we will be a bit stuck, esp if we want to consider usin the 'somthing' that stores keys instead of toring them stright in LDAP. So maybe we can start with allowing just one server to do DNSSEC and source keys from files for now ? The problem is that DNSSEC deployment *on single domain* is 'all or nothing': All DNS servers have to support DNSSEC otherwise the validation on client side can fail randomly. Note that *parent* zone indicates that the particular child zone is secured with DNSSEC by sending DS (delegation signer) record to the client. Validation will fail if client receives DS record from the parent but no signatures are present in data from 'child' zone itself. This prevents downgrade (DNSSEC => plain DNS) attacks. As a result, we have only two options: One DNS server with DNSSEC enabled or arbitrary number DNS servers without DNSSEC, which is very unfortunate. as soon as we have that workign we should also have clearer plans about how we manage keys in LDAP (or elsewhere). Dmitri, Martin and me discussed this proposal in person and the new plan is: - Elect one super-master which will handle key generation (as we do with special CA certificates) - Store generated DNSSEC keys in LDAP - Encrypt stored keys with 'DNSSEC master key' shared by all servers - Derive 'DNSSEC master key' from 'Kerberos master key' during server install/upgrade and store it somewhere on the filesystem (as the Kerberos master key, on each IPA server) - Consider certmonger or oddjob as key generation triggers I think that we should add one new thing - a 'salt' - used for Kerberos master key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC master key as necessary without a change in the Kerberos master key. Does it make sense? Does anybody have any ideas/recommendations which libraries we should use for key derivation and key material en/decryption? Thank you for your time! -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On 19.7.2013 19:55, Simo Sorce wrote: I will reply to the rest of the message later if necessary, still digesting some of your answers, but I wanted to address the following first. On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: The most important question at the moment is "What can we postpone? How fragile it can be for shipping it as part of Fedora 20?" Could we declare DNSSEC support as "technology preview"/"don't use it for anything serious"? Until we figur out proper management in LDAP we will be a bit stuck, esp if we want to consider usin the 'somthing' that stores keys instead of toring them stright in LDAP. So maybe we can start with allowing just one server to do DNSSEC and source keys from files for now ? The problem is that DNSSEC deployment *on single domain* is 'all or nothing': All DNS servers have to support DNSSEC otherwise the validation on client side can fail randomly. Note that *parent* zone indicates that the particular child zone is secured with DNSSEC by sending DS (delegation signer) record to the client. Validation will fail if client receives DS record from the parent but no signatures are present in data from 'child' zone itself. This prevents downgrade (DNSSEC => plain DNS) attacks. As a result, we have only two options: One DNS server with DNSSEC enabled or arbitrary number DNS servers without DNSSEC, which is very unfortunate. as soon as we have that workign we should also have clearer plans about how we manage keys in LDAP (or elsewhere). -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
I will reply to the rest of the message later if necessary, still digesting some of your answers, but I wanted to address the following first. On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: > > The most important question at the moment is "What can we postpone? > How > fragile it can be for shipping it as part of Fedora 20?" Could we > declare > DNSSEC support as "technology preview"/"don't use it for anything > serious"? Until we figur out proper management in LDAP we will be a bit stuck, esp if we want to consider usin the 'somthing' that stores keys instead of toring them stright in LDAP. So maybe we can start with allowing just one server to do DNSSEC and source keys from files for now ? as soon as we have that workign we should also have clearer plans about how we manage keys in LDAP (or elsewhere). Simo. > -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On 17.7.2013 18:25, Simo Sorce wrote: On Tue, 2013-07-16 at 17:15 +0200, Petr Spacek wrote: On 15.7.2013 21:07, Simo Sorce wrote: [...] KSK has to be rolled over manually because it requires changes in parent zone. (It could be automated for sub-zones if their parent zone is also managed by the same IPA server.) Is there any provision for using DNSSEC with private DNS deployments ? Yes, it is. DNSSEC supports 'Islands of Security' [Terminology]: DNS resolvers can be configured with 'trust anchors' explicitly. E.g. 'trust domain example.com only if it is signed by /this/ key, use root key for rest of the Internet' etc. [Terminology] http://tools.ietf.org/html/rfc4033#section-2 This means clients would have to be configured to explicitly trust a specific key for a zone right ? How hard would it be for us to configure IPA clients this way assuming by then we have a DNSSEC aware resolver we can configure on them ? Answer really depends on 'DNSSEC aware resolver we can configure'. Glibc doesn't support DNSSEC validation at all. Fedora 17+ solves this problem via Unbound daemon: Glibc is configured to use local DNS server (127.0.0.1 in /etc/resolv.conf) and local Unbound daemon does the actual resolution and validation. Details are here: https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations Unbound can be configured with custom trust anchor via single line with public key in a configuration file, it is really simple. The problem could be with other clients. I don't know how Windows can handle this. There are some options in Group Policy, but I have no idea what can be configured and what can't. Or is this going to make sense only for IPA deployments that have valid delegation from the public DNS system ? >>> Hmmm I guess that as long as the KSK in the 'parent' zone is imported properly a private deployment of corp.myzone.com using the KSK of myzone.com will work just fine even if corp.myzone.com is not actually delegated but is a private DNS tree ? Or is that incorrect ? AFAIK there *has to be* delegation via DS record [Delegation Signer, DS] from the parent, but IMHO it could work if only the public key for internal zones is published (without any delegation to internal name servers etc.). I didn't try it, so 'here be dragons'. Are there test/zones keys that can be used to experiment ? It is possible to generate own keys, sign own root zone etc. and have own private DNS tree, including the root. The only caveat is that you has to put your 'root key' to each testing client, but it is relatively simple. I did it in lab :-) After some experiments I found that publishing of DS records will not work without proper delegation (including NS records and IP addresses). Delegation from public servers is not usable if the clients can't start from public servers and go down through the tree to the internal servers. Reasons are clear from the top-down verification process, as described in: http://backreference.org/2010/11/17/dnssec-verification-with-dig/ Interesting reading is: https://www.dnssec-tools.org/svn/dnssec-tools/tags/dnssec-tools-1.3/validator/doc/libval-implementation-notes Particularly the section "Top-down versus bottom-up validation" is very interesting. It could work if either internal and external zones are delegated from public DNS (i.e. DS, NS and A/ records are in place) but the internal name servers reply only to internal clients. To conclude it, purely internal deployments require explicit trust anchor configuration in all cases. Moreover, explicit trust anchor configuration will be required if the user/company is paranoid and don't want to publish delegation records for internal zones in public DNS. [...] No, the problem is that we need to define 'who' generates the keys. Remember FreeIPA is a multimaster system, we cannot have potentially conflicting cron jobs running on multiple servers. Right. It sounds like the CRL generation problem. Should we do the same for DNSSEC key regeneration? I.e. select one super-master and let it to handle key regeneration? Or should we find some more robust solution? I'm not against any of these possibilities :-) Falling back to SPOF should be the last resort or a temporary step during development. Sure. Fedora 20 dead lines are really close. Are you okay with something like do-it-in-cron-on-sigle-machine for the first implementation? I would like to avoid SPOF architectures if at all possible. We could devise a way to automatically 'elect' a master, but have all other DNS servers also monitor that keys are regenerated an made available in the expected time frame and if not have one of the other DNS servers try to assume the leader role. I have some ideas hear using priorities etc, but I need to let them brew in my mind a little bit more :) I'm curious! :-) [..] For these reasons I think that we can define new public key attribute in the same way as private key attribute: attributet
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On Tue, 2013-07-16 at 17:15 +0200, Petr Spacek wrote: > On 15.7.2013 21:07, Simo Sorce wrote: > > Is there any place I can read about the format and requirements of these > > files ? > There is no single format, because it is algorithm-dependent. See below. > AFAIK > it is nothing supported by OpenSSL, but I can be wrong. Thanks for attaching examples, it helps. > >> KSK has to be rolled over manually because it requires changes in parent > >> zone. > >> (It could be automated for sub-zones if their parent zone is also managed > >> by > >> the same IPA server.) > > > > Is there any provision for using DNSSEC with private DNS deployments ? > Yes, it is. DNSSEC supports 'Islands of Security' [Terminology]: DNS > resolvers > can be configured with 'trust anchors' explicitly. E.g. 'trust domain > example.com only if it is signed by /this/ key, use root key for rest of the > Internet' etc. > > [Terminology] http://tools.ietf.org/html/rfc4033#section-2 This means clients would have to be configured to explicitly trust a specific key for a zone right ? How hard would it be for us to configure IPA clients this way assuming by then we have a DNSSEC aware resolver we can configure on them ? > > Or is this going to make sense only for IPA deployments that have valid > > delegation from the public DNS system ? > > > > Hmmm I guess that as long as the KSK in the 'parent' zone is imported > > properly a private deployment of corp.myzone.com using the KSK of > > myzone.com will work just fine even if corp.myzone.com is not actually > > delegated but is a private DNS tree ? > > Or is that incorrect ? > > AFAIK there *has to be* delegation via DS record [Delegation Signer, DS] from > the parent, but IMHO it could work if only the public key for internal zones > is published (without any delegation to internal name servers etc.). I didn't > try it, so 'here be dragons'. Are there test/zones keys that can be used to experiment ? [..] > >> Initial key generation is closely related to the question how should we > >> handle > >> (periodic) key regeneration? (e.g. "Generate new ZSK each month.") > > > > We only really need to generate (or import) the KSK of the parent zone, > It seems that there is slight misunderstanding. KSK is the 'master key' for > particular zone. This master key (KSK) signs other keys (ZSKs) and data are > signed by ZSKs. Sorry I expressed myself badly, I mean we only need to generate one KSK at install time and make it available to the admin to be signed by the upper zone admins. But then all other keys including the ZSKs can be completely managed within IPA w/o explicit admin work if we have the right tooling. [..] > > No, the problem is that we need to define 'who' generates the keys. > > Remember FreeIPA is a multimaster system, we cannot have potentially > > conflicting cron jobs running on multiple servers. > Right. It sounds like the CRL generation problem. Should we do the same for > DNSSEC key regeneration? I.e. select one super-master and let it to handle > key > regeneration? Or should we find some more robust solution? I'm not against > any > of these possibilities :-) Falling back to SPOF should be the last resort or a temporary step during development. I would like to avoid SPOF architectures if at all possible. We could devise a way to automatically 'elect' a master, but have all other DNS servers also monitor that keys are regenerated an made available in the expected time frame and if not have one of the other DNS servers try to assume the leader role. I have some ideas hear using priorities etc, but I need to let them brew in my mind a little bit more :) [..] > >> For these reasons I think that we can define new public key attribute in > >> the > >> same way as private key attribute: > >> attributetypes: ( x.x.x.x.x NAME 'idnsSecPublicKey' SYNTAX > >> 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) > >> > >> The resulting object class could be: > >> objectClasses: ( x.x.x.x.x NAME 'idnsSecKeyPair' DESC 'DNSSEC key pair' SUP > >> top STRUCTURAL MUST ( cn $ idnsSecPrivateKey $ idnsSecPublicKey ) ) > > > > Will bind read these attributes ? > > Or will we have to dump these values into files via bind-dyndb-ldap for > > bind9 to read them back ? > AFAIK it has to be in files: Private key in one file and public key in the > other file. I can't find any support for reading private keys from buffers. Ok so to summarize we basically are going to load the private key file in idnsSecPrivateKey and the public key file in idnsSecPublicKey as blobs and the have bind-dyndb-ldap fetch them and save them into files that bind can access. This means bind-dyndb-ldap will need to grow the ability to also clean p and synchronize the files over time. So there will need to be hooks to regularly check all needed files are in place and obsolete ones are deleted. Maybe we can grow a companion python helper to do this, as it is a relatively simple task, that is not performance crit
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
On 15.7.2013 21:07, Simo Sorce wrote: On Mon, 2013-07-15 at 16:58 +0200, Petr Spacek wrote: The remaining part is mostly about key management. Following text mentions 'DNSSEC keys' many times, so I tried to summarize how keys are used in DNSSEC. Feel free to skip it. == DNSSEC theory == Each zone has *at least* two key pairs. They are called Key Signing Key (KSK, the first key pair) and Zone Signing Key (ZSK, the second key pair). - *Parent* zone contains a copy of public part of the KSK. - Zone itself contains public part of ZSK (and KSK). - Client uses public part of KSK (obtained from secure parent zone) for ZSK verification. - ZSK is used for signing of the real data in the zone (i.e. generating RRSIG records) and verification on client side. Each key and signature contains key-id, so one zone can be signed by multiple KSKs and ZSKs at the same time. This solves the key roll over problem. Each key contains this set of timestamps: Created, Revoke - self descriptive :-) Publish - public part of the key will be visible in zone after this time Active - new signatures with this key can be generated after this time Inactive - new signatures with this key cannot be generated after this time Delete - public part of the key will deleted from the zone after this time NIST says [1] that KSK should be changed ~ each 1-3 years (it requires change in parent zone) and ZSK should be changed ~ each 1-3 months. The recommendation says [1] that zone should have two ZSKs: One Active (used for signature generation) and second only Published (ready for roll over in case of emergency/when the first key pair expires). This mitigates problems with caches and stale key material during roll-over. BIND 9 can do signature maintenance/ZSK key roll over automatically. It needs only keys stored in files (with proper timestamps) and all signatures will be generated & removed when the right time passes. Is there any place I can read about the format and requirements of these files ? There is no single format, because it is algorithm-dependent. See below. AFAIK it is nothing supported by OpenSSL, but I can be wrong. KSK has to be rolled over manually because it requires changes in parent zone. (It could be automated for sub-zones if their parent zone is also managed by the same IPA server.) Is there any provision for using DNSSEC with private DNS deployments ? Yes, it is. DNSSEC supports 'Islands of Security' [Terminology]: DNS resolvers can be configured with 'trust anchors' explicitly. E.g. 'trust domain example.com only if it is signed by /this/ key, use root key for rest of the Internet' etc. [Terminology] http://tools.ietf.org/html/rfc4033#section-2 Or is this going to make sense only for IPA deployments that have valid delegation from the public DNS system ? Hmmm I guess that as long as the KSK in the 'parent' zone is imported properly a private deployment of corp.myzone.com using the KSK of myzone.com will work just fine even if corp.myzone.com is not actually delegated but is a private DNS tree ? Or is that incorrect ? AFAIK there *has to be* delegation via DS record [Delegation Signer, DS] from the parent, but IMHO it could work if only the public key for internal zones is published (without any delegation to internal name servers etc.). I didn't try it, so 'here be dragons'. Normally it should work this way: . (root zone is signed with well known key) - root contains DS record for com. - DS contains hash of the public key used in com. domain com. - DNSKEY record contains whole public key for domain com. - key is accepted only if hash of the key matches DS record from parent (.) - DS record for example.com. is stored in com. example.com. - DNSKEY record contains whole public key for domain example.com. - the key is accepted only if hash of the key matches DS record from parent (com.) etc. Client walks from the root zone down to the desired record and verifies signatures with keys obtained from DNSKEY record. The DNSKEY record itself has to be authenticated by DS -> DNSKEY -> DS -> DNSKEY -> ... -> DNSKEY chain (from root down to the zone). Yes, publishing of DS record creates information leak - about existence of a sub-domain - but this information leaks anyway in e-mail headers etc. IMHO it is much better than messing with private Trust Anchors etc. [DS] http://tools.ietf.org/html/rfc4034#section-5 == End of DNSSEC theory == 1) How will we handle generation of key pairs? How will externally generated keys be imported? Personally, I would start with 'classical' command line utilities like dnssec-keygen etc. and extend 'ipa' tool to import generated keys. (Import = read keys from text files and create appropriate attributes to LDAP.) If you mean to do this as part of the ipa-dns-install script or additional script (eg ipa-dnssec-enable) I am fine. I am not ok with asking admins to manually run these commands. Okay. I meant something like extension of 'ipa'
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
[..] Removed first part that deals with old matters and keeping only the new part. Comments inline as usual. Simo. On Mon, 2013-07-15 at 16:58 +0200, Petr Spacek wrote: > The remaining part is mostly about key management. > > Following text mentions 'DNSSEC keys' many times, so I tried to summarize how > keys are used in DNSSEC. Feel free to skip it. > > == DNSSEC theory == > > Each zone has *at least* two key pairs. They are called Key Signing Key (KSK, > the first key pair) and Zone Signing Key (ZSK, the second key pair). > > - *Parent* zone contains a copy of public part of the KSK. > - Zone itself contains public part of ZSK (and KSK). > - Client uses public part of KSK (obtained from secure parent zone) for ZSK > verification. > - ZSK is used for signing of the real data in the zone (i.e. generating RRSIG > records) and verification on client side. > > Each key and signature contains key-id, so one zone can be signed by multiple > KSKs and ZSKs at the same time. This solves the key roll over problem. > > Each key contains this set of timestamps: > Created, Revoke - self descriptive :-) > Publish - public part of the key will be visible in zone after this time > Active - new signatures with this key can be generated after this time > Inactive - new signatures with this key cannot be generated after this time > Delete - public part of the key will deleted from the zone after this time > > NIST says [1] that KSK should be changed ~ each 1-3 years (it requires change > in parent zone) and ZSK should be changed ~ each 1-3 months. > > The recommendation says [1] that zone should have two ZSKs: One Active (used > for signature generation) and second only Published (ready for roll over in > case of emergency/when the first key pair expires). This mitigates problems > with caches and stale key material during roll-over. > > BIND 9 can do signature maintenance/ZSK key roll over automatically. It needs > only keys stored in files (with proper timestamps) and all signatures will be > generated & removed when the right time passes. Is there any place I can read about the format and requirements of these files ? > KSK has to be rolled over manually because it requires changes in parent > zone. > (It could be automated for sub-zones if their parent zone is also managed by > the same IPA server.) Is there any provision for using DNSSEC with private DNS deployments ? Or is this going to make sense only for IPA deployments that have valid delegation from the public DNS system ? Hmmm I guess that as long as the KSK in the 'parent' zone is imported properly a private deployment of corp.myzone.com using the KSK of myzone.com will work just fine even if corp.myzone.com is not actually delegated but is a private DNS tree ? Or is that incorrect ? > == End of DNSSEC theory == > > > > 1) How will we handle generation of key pairs? How will externally generated > keys be imported? > > Personally, I would start with 'classical' command line utilities like > dnssec-keygen etc. and extend 'ipa' tool to import generated keys. (Import = > read keys from text files and create appropriate attributes to LDAP.) If you mean to do this as part of the ipa-dns-install script or additional script (eg ipa-dnssec-enable) I am fine. I am not ok with asking admins to manually run these commands. > Initial key generation is closely related to the question how should we > handle > (periodic) key regeneration? (e.g. "Generate new ZSK each month.") We only really need to generate (or import) the KSK of the parent zone, our code should be able to generate any other key, and sign it. > Is it okay to use normal cron job to handle the key generation? I.e. to call > dnssec-keygen with proper parameters each month and store the result in LDAP? No, the problem is that we need to define 'who' generates the keys. Remember FreeIPA is a multimaster system, we cannot have potentially conflicting cron jobs running on multiple servers. > Or should we teach certmonger to take care of DNSSEC keys? Certmonger would > have to call dnssec-keygen and to do some IPA calls. (I assume that key > parsing and import will be handled by IPA framework.) certmonger might have the same issue as a cronjob, how do we know *which* one of 3 DNS server should run the updating job ? Should we just leave it to chance and the first win ? What if 2 end up trying to create new keys at exactly the same time ? > We can postpone the key management for the first version and just provide > interface for key removal and import from file. Well all this key management will be a FreeIPA issue, from the bind-dyndb-ldap development pov we need to provide the mechanism and can certainly defer the key management part, but we will not be able to offer this feature until that is done. > 2) Second question is how and where keys should be stored. AFAIK BIND 9 > expects that keys will be stored in file system: One key pair as two files in > specified
Re: [Freeipa-devel] DNSSEC support design considerations: key material handling
Hello, first pair of this message quickly concludes discussion about database part of the DNSSEC support and then key material handling is discussed. I'm sorry for the wall of text. On 27.6.2013 18:43, Simo Sorce wrote: > >* How to get sorted list of entries from LDAP? Use LDAP > > server-side sorting? Do we have necessary indices? > > > >We can do client side sorting as well I guess, I do not have a strong > >opinion here. The main reason why you need ordering is to detect delete > >records right ? >Exactly. I realized that server-side sorting doesn't make sense because we >plan to use syncrepl, so there is nothing to sort - only the flow of >incremental updates. Syncrepl includes notice of deletions too, right ? Yes. Client receives delete notification with entryUUID, so we can unambiguously identify the deleted entry. I wrote example LDAP client and it works (against OpenLDAP :-). > (Filesystem) cache maintenance > Questions: How often should we save the cache from operating memory to disk? Prerequisite to be able to evaluate this question. How expensive is it to save the cache ? My test zone contains 65535 records, 255 A records, 1 SOA + 1 NS record. Benchmark results: zone dump < 0.5 s (to text file) zone load < 1 s (from text file) zone delete < 9 s (LOL. This is caused by implementation details of RBTDB.) LDAP search on the whole sub-tree: < 15 s Ouch, this looks very slow, missing indexes ?) I don't see any 'notes=U' in access log. Also, my OpenLDAP instance with the same DNS data can do the same search < 2 seconds. Is this just the search? or is it search + zone load ? Just the search. Load time for bind-dyndb-ldap 3.x: < 120 s So, a reload from scratch can take many 10s of seconds on big zones, did this test include DNSSEC signing ? Or would we need to add that on top ? The time is for plain load. Current code is horribly ineffective and generates one extra LDAP search for each update. This madness will be eliminated by syncrepl, so the plain load time should be cut to much smaller value. We will see. The other problem is that current code serializes a lot of work. This also will be mitigated to certain level (not completely, for now). Originally, I planed to write a script which would compare data in LDAP with zone file on disk. This script could be used for debugging & automated testing, so we can assess if the code behaves correctly and decide if we want to implement automatic re-synchronization when necessary. Wouldn't this script be subject to races depending at what time it is accessing either LDAP or the file ? Yes, it would. The script was intended for 'lab use': 1. Run DNS server. 2. Do big amount of dynamic updates in short time. 3. Shutdown DNS and LDAP servers. 4. Compare data in DNS database with data in LDAP. This could tell us how often and how many inconsistencies occur. After that we can make up some re-synchronization intervals etc. The main issue here is that it is hard to know when doing a full re-sync is necessary. And because it is expensive I am wary of doing it automatically too often. However perhaps a timed event so it is done once a day it is not a bad idea. I agree. I think that we sorted out necessary changes in storage/database part of the DNSSEC integration. The remaining part is mostly about key management. Following text mentions 'DNSSEC keys' many times, so I tried to summarize how keys are used in DNSSEC. Feel free to skip it. == DNSSEC theory == Each zone has *at least* two key pairs. They are called Key Signing Key (KSK, the first key pair) and Zone Signing Key (ZSK, the second key pair). - *Parent* zone contains a copy of public part of the KSK. - Zone itself contains public part of ZSK (and KSK). - Client uses public part of KSK (obtained from secure parent zone) for ZSK verification. - ZSK is used for signing of the real data in the zone (i.e. generating RRSIG records) and verification on client side. Each key and signature contains key-id, so one zone can be signed by multiple KSKs and ZSKs at the same time. This solves the key roll over problem. Each key contains this set of timestamps: Created, Revoke - self descriptive :-) Publish - public part of the key will be visible in zone after this time Active - new signatures with this key can be generated after this time Inactive - new signatures with this key cannot be generated after this time Delete - public part of the key will deleted from the zone after this time NIST says [1] that KSK should be changed ~ each 1-3 years (it requires change in parent zone) and ZSK should be changed ~ each 1-3 months. The recommendation says [1] that zone should have two ZSKs: One Active (used for signature generation) and second only Published (ready for roll over in case of emergency/when the first key pair expires). This mitigates problems with caches and stale key material dur
