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 standard&tool 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 > > >>>> 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 ?
Actually an idea came to mind that might work well enough. We could store the symmetric key wrapped itself. The wrapping would be done using a public key per DNS server. Public keys for DNS servers would be generated via certmonger in the usual way. 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. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
