[Freeipa-devel] DNSSEC design page: key wrapping

Tue Mar 4 21:53:53 UTC 2014

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York