[Freeipa-devel] DNSSEC design page: key wrapping

Tue Mar 4 22:16:53 UTC 2014

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 at 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 ?
>>>> 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
>> IPA-specific hacks, let's use a standard.
> Standards are fine. That's not the point though.
>
>>> Although I realize I have not said it explicitly before I am not all
>>> that happy to have a generic pkcs#11 storage in IPA. Storing *arbitrary
>>> private* keys in my mind is clearly the job of DRM which has been built
>>> with that specific use case in mind and has all the appropriate
>>> protections. Putting unencrypted private keys in the IPA tree is IMHO a
>>> too high risk.
>> Oh wait, I think we misunderstood each other. I'm not proposing to store any
>> keys unencrypted (in IPA)! I only want to design the LDAP schema not to be
>> IPA-specific, nothing else.
>>
>> In case of IPA we can always encrypt all keys (when we have vault available).
>> I hope this clears the misunderstanding.
> Well if the Vault is the storage, then why do we care for an LDAP
> schema ?
>
> I think Vault is the right storage for user custom data or application
> custom data.
>
> I am not sure we want to depend on the vault for DNS, because it needs
> high availability, however given we copy the keys on the local
> filesystem, once generated, perhaps the Vault is sufficient if it is a
> replicated system. I am not sure DRM is replicated, or will be
> replicated in the first incarnation, so that's why I am treating DNS
> differently.
>
>>> I am not against creating a generic schema if we think it may be useful
>>> for others, but the more I thin of it the less I think we should use it
>>> for anything but DNS keys and they should be definitely encrypted in
>>> LDAP and the DNS server machines should be the only ones able to decrypt
>>> them.
>> Even if all keys will be encrypted?
> ELOOP ? :)
>
>>> A casual search with directory manager should never yield private keys.
>> It makes sense. As I said above, all keys should be encrypted when the
>> proposed schema will be used as part of IPA.
>>
>>
>> Anyway, should we use vault for key storage from the beginning and do not
>> spend time on a throw-away schema design etc.?
>>
>> I can see the reasoning and we don't need two mechanisms for the same thing.
> Right.
>
> 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.
>
> 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.

The DRM storage is replicated. This is the whole point.
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. 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.

2c.

>
> Simo.
>

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/