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 ? Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
