[Freeipa-devel] DNSSEC design page: key wrapping

Wed Mar 5 16:56:25 UTC 2014

On 5.3.2014 16:02, Petr Spacek wrote:
> 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.

Petr requested a diagram for this scenario; see attachment.

>
> - CA certs will be pulled from cn=CAcert,cn=ipa,cn=etc,dc=ipa,dc=example
> and transformed to required format. ("PKCS-CA-provider")

(note: actually, not cn=CAcert)

> - 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.

+1

>
> 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.
>

-- 
Jan Cholasta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sssd-pkcs11.svg
Type: image/svg+xml
Size: 23406 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140305/d29cc27d/attachment.svg>