Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 7.3.2014 17:33, Dmitri Pal wrote: I do not think it is the right architectural approach to try to fix a specific use case with one off solution while we already know that we need a key storage. I would rather do things right and reusable than jam them into the currently proposed release boundaries. I want to make clear that I'm not opposed to Vault in general. I'm questioning the necessity of Vault from the beginning because it will delay DNSSEC significantly. One of the proposals in this thread is to use something simple for DNSSEC keys (with few lines of Python code) and migrate DNSSEC with Vault when Vault is available and stable enough (in some later release). I understand that Vault brings a lot of work to the table. But let us do it right and if it does not fit into 4.0 let us do it in 4.1. We will have one huge release with DNSSEC + Vault at once if we to postpone DNSSEC to the same release as Vault. As a result, it would be harder to debug it because we will have to find if something is broken because of: - DNSSEC-IPA integration - Vault-IPA integration - DNSSEC-Vault integration. I don't think it is a good idea to make such huge release. Release early, release often -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/10/2014 11:49 AM, Petr Spacek wrote: On 7.3.2014 17:33, Dmitri Pal wrote: I do not think it is the right architectural approach to try to fix a specific use case with one off solution while we already know that we need a key storage. I would rather do things right and reusable than jam them into the currently proposed release boundaries. I want to make clear that I'm not opposed to Vault in general. I'm questioning the necessity of Vault from the beginning because it will delay DNSSEC significantly. +1, I also now see number of scenarios where Vault will be needed. One of the proposals in this thread is to use something simple for DNSSEC keys (with few lines of Python code) and migrate DNSSEC with Vault when Vault is available and stable enough (in some later release). I understand that Vault brings a lot of work to the table. But let us do it right and if it does not fit into 4.0 let us do it in 4.1. We will have one huge release with DNSSEC + Vault at once if we to postpone DNSSEC to the same release as Vault. As a result, it would be harder to debug it because we will have to find if something is broken because of: - DNSSEC-IPA integration - Vault-IPA integration - DNSSEC-Vault integration. I don't think it is a good idea to make such huge release. Release early, release often I must say I tend to agree with Petr. If the poor man's solution of DNSSEC without Vault does not cost us too much time and it would seem that the Vault is not going to squeeze in 4.0 deadlines, I would rather release the poor man's solution in 4.0 and switch to Vault when it's available in 4.1. This would let our users test the non-Vault parts of our DNSSEC solution instead of waiting to test a perfect solution. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 6.3.2014 16:56, Jakub Hrozek wrote: On Wed, Mar 05, 2014 at 05:56:25PM +0100, Jan Cholasta wrote: On 5.3.2014 16:02, Petr Spacek wrote: a) Do not invent any new schema for certificates and public keys. A set of PKCS-providers in SSSD will aggregate the data from various sources and transform them to appropriate format. A heavy machinery in SSSD will convert existing data in IPA LDAP tree to PKCS#11 objects presented over PKCS#11 interface. Petr requested a diagram for this scenario; see attachment. Awesome, this is helpful for someone like me who hasn't been following the whole thread on freeipa-devel into the detail. Given that you plan on implementing an AD provider as well, I guess it would make sense to also implement (but maybe not expose unless there is a common schema) a purre LDAP provider that both IPA and AD would share? I did not include pure LDAP only because that would make the diagram too big ;-) Are you going to turn this e-mail into a design page and file SSSD tickets? Who's going to own the feature in SSSD, you, Petr or both? Me, I guess, at least the generic bits and the part related to certificates. I will create a design page. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/05/2014 11:06 AM, Simo Sorce wrote: On Wed, 2014-03-05 at 16:29 +0100, Martin Kosek wrote: On 03/05/2014 03:04 PM, Simo Sorce wrote: On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. Yeah, but the plan is not force people to have the heavy weight Java infrastructure on each server so that they are able to create more lightweight servers only with components they choose: https://fedorahosted.org/freeipa/ticket/4058 Yes, but the Vault does not need to be installed on each server, just on a couple of them like for the CA. In particular it doesn't need to be installed on the same servers that offer the DNS service. Simo. I agree with Simo. From the big picture perspective we have more and more use cases when Vault becomes a requirement: a) Storing passwords for users - initial case b) Storing volume keys for Cinder - OpenStack - Barbican use case c) Storing passwords for external cloud provider accounts - deltacloud/Manage IQ use case d) Storing DNSSEC keys - your use case e) Storing private keys for users - classical PKI escrow the DRM was built for f) Storing private SSH key - there is a ticket for that kind of escrow functionality too. For me it is apparent that vault will be a default component. It is not as heavy weight now as it used to be. All Dogtag components can share same tomcat instance so if you have a CA on the system your incremental impact is very small. So what we need is: a) Solve the problem of the DRM install. Single server work was done by Rob. Ade will be able to take it over and hel;p with the DRM install across several servers (with replication). b) There is REST API for Vault it requires certificate authentication for now. No Kerberos. We can probably live without Kerberos for now since SSSD has host cert. c) We need to hook some kind of access control that would allow specifying policies about who can fetch which keys (this is regardless where they are stored Vault or LDAP) I do not think it is the right architectural approach to try to fix a specific use case with one off solution while we already know that we need a key storage. I would rather do things right and reusable than jam them into the currently proposed release boundaries. I understand that Vault brings a lot of work to the table. But let us do it right and if it does not fit into 4.0 let us do it in 4.1. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Wed, Mar 05, 2014 at 05:56:25PM +0100, Jan Cholasta wrote: On 5.3.2014 16:02, Petr Spacek wrote: On 5.3.2014 14:21, Simo Sorce wrote: On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). Works for me. The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... Let me summarize what we have: We agree that = - PKCS#11 is the right interface for key manipulation
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Marti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). Works for me. The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... 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 design page: key wrapping
On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. 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 design page: key wrapping
On 5.3.2014 14:21, Simo Sorce wrote: On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. Sounds good. (But I must admit I was a little bit scared for a moment :-) - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). Works for me. +1 The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... Simo. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 5.3.2014 14:21, Simo Sorce wrote: On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). Works for me. The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... Let me summarize what we have: We agree that = - PKCS#11 is the right interface for key manipulation and certificate retrieval. - We can have PKCS#11 client library talking to local SSSD so the data retrieval logic can be hidden in SSSD (something like PKCS-responder). Open questions/variants to
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/05/2014 03:04 PM, Simo Sorce wrote: On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. Yeah, but the plan is not force people to have the heavy weight Java infrastructure on each server so that they are able to create more lightweight servers only with components they choose: https://fedorahosted.org/freeipa/ticket/4058 Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Wed, 2014-03-05 at 16:29 +0100, Martin Kosek wrote: On 03/05/2014 03:04 PM, Simo Sorce wrote: On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. Yeah, but the plan is not force people to have the heavy weight Java infrastructure on each server so that they are able to create more lightweight servers only with components they choose: https://fedorahosted.org/freeipa/ticket/4058 Yes, but the Vault does not need to be installed on each server, just on a couple of them like for the CA. In particular it doesn't need to be installed on the same servers that offer the DNS service. 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 design page: key wrapping
On 5.3.2014 16:02, Petr Spacek wrote: On 5.3.2014 14:21, Simo Sorce wrote: On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: On 5.3.2014 08:48, Jan Cholasta wrote: On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11-BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). Works for me. The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... Let me summarize what we have: We agree that = - PKCS#11 is the right interface for key manipulation and certificate retrieval. - We can have PKCS#11 client library talking to local SSSD so the data retrieval logic can be hidden in SSSD (something like
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve the DNA plugin issue with the ability to use groups for
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve the DNA plugin issue with the ability to use groups for authentication I guess we could build a control/extend operation that
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve the DNA plugin issue with the ability to use groups for authentication I guess we could
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve the DNA
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 4.3.2014 21:25, Petr Spacek wrote: On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed.
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers?
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve the DNA plugin issue with the ability to use groups for authentication I guess we could build a control/extend operation that would allow masters to transfer keys to each other w/o exposing them as LDAP searches, do we want to try to go in that direction ? Simo. Should we consider vault as a storage for these keys too? It already supports recovery of the symmetric and asymmetric keys so may be these keys should be stored there? Maybe. The question is if we want to support DNSSEC without Dogtag ... Without Dogtag? Vault would be an independent component from CA I assume, though CA might be needed anyways to issue transport keys for the internal components. But I think that even if we use Vault as an internal password and key storage I do not see a reason why we can't require it for DNSSEC. Why over-complicate things if we already have components that can be used? If we see a requests to support DNSSEC without Vault component we will adjust but I do not think we should limit ourselves in the first implementation. I'm personally fine with that. Are we going to re-prioritize Password Vault from Backlog to 4.0? https://fedorahosted.org/freeipa/ticket/3872 We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo that key wrapping is not necessary :-) For 4.0 we could document that you have to copy the keys around manually. And add Vault support in 4.1 ? It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping key to replica file to make it easier? Can the vault approach work for Kerberos master key? If not, shouldn't we design something universal instead of deferring it again and again? We can use the same method for the M/K, now that the CA is installed before the rest we do not have a chicken-egg issue anymore. Another problem is that the PKCS#11 LDAP schema was designed as application-independent but now we are adding very specific key-wrapping mechanism (it is hard to believe that somebody else will implement it). It could be optional. Maybe we can add something like attribute 'pkcs11keyWrapMech': - key is not wrapped if it is not present - key is wrapped if it is present - value determines used mechanism (mandatory mechanism to implement is only 'none') What is 'none' ? I mean 'attribute is not present'. The only unknown here is who adds a new wrapper wen a new server is up and it publishes the public key in LDAP. For existing servers they can re-wrap themselves. It's a few layers but should not be too hard. I don't fully understand to your proposal but I'm afraid that it will not work for ordinary IPA users. Don't forget that we want to have universal PKCS#11 storage usable even for private SSH keys and other stuff. Well ... TBH I am not really that hot about storing private keys in IPA like that, however for people that want to do it they can simply store them not encrypted as you proposed above. Please correct me if I'm wrong. You are right, but I was caring for the DNS keys case, not the user's ssh key case, which is hairy IMHO. There is no difference between DNSSEC keys and any other keys except the fact that we need shared wrapping key for DNSSEC. Nothing else. Note that SSH private key is just an example. You can use PKCS#11 as storage for user certificates used for authentication in Firefox etc. I think the private ssh key case is a clear job for the Vault the fact sssd might use a pkcs#11 interface to present it to ssh, or the user simply pulls it to the local file system is, in my view, an implementation detail. I can see a huge difference. Properly implemented PKCS#11 provides you the same separation as GSS-Proxy for keytabs. I.e. non-root process will not be able to extract any private keys. Also, PKCS#11 is a standard so any application can use it. I don't like
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 04:53 PM, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 05:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve the DNA plugin issue with the ability to use groups for authentication I guess we could build a control/extend operation that would allow masters to transfer keys to each other w/o exposing them as LDAP searches, do we want to try to go in that direction ? Simo. Should we consider vault as a storage for these keys too? It already supports recovery of the symmetric and asymmetric keys so may be these keys should be stored there? Maybe. The question is if we want to support DNSSEC without Dogtag ... Without Dogtag? Vault would be an independent component from CA I assume, though CA might be needed anyways to issue transport keys for the internal components. But I think that even if we use Vault as an internal password and key storage I do not see a reason why we can't require it for DNSSEC. Why over-complicate things if we already have components that can be used? If we see a requests to support DNSSEC without Vault component we will adjust but I do not think we should limit ourselves in the first implementation. I'm personally fine with that. Are we going to re-prioritize Password Vault from Backlog to 4.0? https://fedorahosted.org/freeipa/ticket/3872 We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo that key wrapping is not necessary :-) For 4.0 we could document that you have to copy the keys around manually. And add Vault support in 4.1 ? It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping key to replica file to make it easier? Can the vault approach work for Kerberos master key? If not, shouldn't we design something universal instead of deferring it again and again? We can use the same method for the M/K, now that the CA is installed before the rest we do not have a chicken-egg issue anymore. Another problem is that the PKCS#11 LDAP schema was designed as application-independent but now we are adding very specific key-wrapping mechanism (it is hard to believe that somebody else will implement it). It could be optional. Maybe we can add something like attribute 'pkcs11keyWrapMech': - key is not wrapped if it is not present - key is wrapped if it is present - value determines used mechanism (mandatory mechanism to implement is only 'none') What is 'none' ? I mean 'attribute is not present'. The only unknown here is who adds a new wrapper wen a new server is up and it publishes the public key in LDAP. For existing servers they can re-wrap themselves. It's a few layers but should not be too hard. I don't fully understand to your proposal but I'm afraid that it will not work for ordinary IPA users. Don't forget that we want to have universal PKCS#11 storage usable even for private SSH keys and other stuff. Well ... TBH I am not really that hot about storing private keys in IPA like that, however for people that want to do it they can simply store them not encrypted as you proposed above. Please correct me if I'm wrong. You are right, but I was caring for the DNS keys case, not the user's ssh key case, which is hairy IMHO. There is no difference between DNSSEC keys and any other keys except the fact that we need shared wrapping key for DNSSEC. Nothing else. Note that SSH private key is just an example. You can use PKCS#11 as storage for user certificates used for authentication in Firefox etc. I think the private ssh key case is a clear job for the Vault the fact sssd might use a pkcs#11 interface to present it to ssh, or the user simply pulls it to the local file system is, in my view, an implementation detail. I can see a huge difference. Properly implemented PKCS#11 provides you the same separation as GSS-Proxy for keytabs. I.e. non-root process will not be able to extract any
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 4.3.2014 23:18, Dmitri Pal wrote: We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so we need to design schema for *public* data. All private data can be stored in Vault if we agree on that. Do we need it on the server and if so can it be exposed by the vault rather than via LDAP? We need standard PKCS#11 interface because applications like BIND and OpenDNSSEC do not care about IPA-specifics. However applications see only PKCS#11 interface and nothing else, there could be LDAP or some other protocol behind the API. Honza's plan is to integrate PKCS#11 module to SSSD somehow so it will be available on all client machines, it will use caching facilities, fail-over etc. Replying to the other thread to join both threads to one: Also about PKCS#11 interface. I am all for PKCS#11 interface for client exposed from SSSD that uses whatever means to fetch the central keys it being SSH keys, gnome keyring keys or something else. AFAIK that is exactly the plan. I do not see a reason for IPA to expose a remote PKCS#11 interface. If we need a remote PKCS#11 interface (please insert why here) then it should be a part of the vault API rather than anything else. I'm not sure that I understand... PKCS#11 is just a set of functions, for an application it is a library. An application just calls the PKCS#11 API and knows nothing about implementation details so there is nothing like 'remote PKCS#11'. As I said above, SSSD will be behind scenes. Everything is local except the data storage in LDAP or vault, it doesn't matter. Maybe I misunderstood you, sorry. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 05:30 PM, Petr Spacek wrote: On 4.3.2014 23:18, Dmitri Pal wrote: We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so we need to design schema for *public* data. All private data can be stored in Vault if we agree on that. Do we need it on the server and if so can it be exposed by the vault rather than via LDAP? We need standard PKCS#11 interface because applications like BIND and OpenDNSSEC do not care about IPA-specifics. However applications see only PKCS#11 interface and nothing else, there could be LDAP or some other protocol behind the API. Honza's plan is to integrate PKCS#11 module to SSSD somehow so it will be available on all client machines, it will use caching facilities, fail-over etc. Replying to the other thread to join both threads to one: Also about PKCS#11 interface. I am all for PKCS#11 interface for client exposed from SSSD that uses whatever means to fetch the central keys it being SSH keys, gnome keyring keys or something else. AFAIK that is exactly the plan. I do not see a reason for IPA to expose a remote PKCS#11 interface. If we need a remote PKCS#11 interface (please insert why here) then it should be a part of the vault API rather than anything else. I'm not sure that I understand... PKCS#11 is just a set of functions, for an application it is a library. An application just calls the PKCS#11 API and knows nothing about implementation details so there is nothing like 'remote PKCS#11'. As I said above, SSSD will be behind scenes. Everything is local except the data storage in LDAP or vault, it doesn't matter. Maybe I misunderstood you, sorry. Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 5.3.2014 05:10, Simo Sorce wrote: On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are stored in the Vault and they can be files in the format used by bind ? So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. Simo. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
