[Freeipa-devel] DNSSEC design page: key wrapping

Wed Mar 5 15:02:33 UTC 2014

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 discuss are
==============
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.

- CA certs will be pulled from cn=CAcert,cn=ipa,cn=etc,dc=ipa,dc=example and 
transformed to required format. ("PKCS-CA-provider")
- Other data except DNSSEC keys (like user certificates) will be handled 
specially by special provider. (Most likely this provider will stay 
unimplemented :-))
- DNS public keys can be stored as DNS records and converted to format 
appropriate for PKCS#11 somehow. One problem is that sometimes you need to 
generate keys but do not publish them in DNS zone. Situations like this will 
require special handling. ("PKCS-DNSSEC-provider")
- DNS private keys are special case because they require special handling for 
key wrapping. Sub-variant are:
  aa) Use IPA vault. It requires Vault support in IPA 4.0 (for DNSSEC) and 
also client-side support in SSSD. (special "PKCS-DNSSEC-vault-provider")
  ab) Use some simpler single-purpose key wrapping mechanism designed 
specially for DNSSEC. Implement the key un/wrapping in special code path in 
SSSD. ("PKCS-DNSSEC-simple-provider")

b) Use a new schema for generic PKCS#11 module in LDAP. The generic 
"PKCS-ldap-provider" will simply 1:1 map the data in LDAP to objects presented 
over PKCS#11 interface.
- DNS public keys, CA certs and generally all public data will be stored in 
the new schema in plain text.
- This approach supports user certificates and all other use cases out of the box.
- Private keys needs special handling:
  aa) Use IPA vault. It requires Vault support in IPA 4.0 (for DNSSEC) and 
also client-side support in SSSD.
  ab) Use some simpler single-purpose key wrapping mechanism. (Proposal with 
wrapping keys stored in LDAP is on the mailing list.) Implement the key 
un/wrapping in special code path in "PKCS-ldap-provider". The difference is 
that now we don't need to call any REST API from SSSD and we can read all the 
data from LDAP or file system.

Personally, I agree with the pluggable approach with various PKCS providers 
but I still can see the value in variant (b) with LDAP schema designed 
specifically for PKCS#11.

It enables us to use generic PKCS#11 interface in all applications and we do 
not need to tweak SSSD providers specifically for each use case. IMHO it is 
also easier to implement on SSSD side of things. The only problem is that we 
didn't agree on a key wrapping mechanism.

Maybe we can start with generic LDAP schema and some simple key wrapping 
mechanism for now and gradually add support for Vault in the future. SSSD will 
be pluggable so we will not be tied to the simpler mechanism forever.

Also, I'm not insisting on storing wrapping keys in LDAP. In theory, we could 
store one wrapping key per-user on disk and let SSSD to read that key when 
user logs in.

Let's finally decide what to do! Please keep in mind that we need something 
feasible and reasonably secure for DNSSEC and CA rotation 4.0.

-- 
Petr^2 Spacek