[Freeipa-devel] DNSSEC design page: key wrapping

Thu Mar 6 15:56:10 UTC 2014

On Wed, Mar 05, 2014 at 05:56:25PM +0100, Jan Cholasta wrote:
> 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.

Awesome, this is helpful for someone like me who hasn't been following
the whole thread on freeipa-devel into the detail.

Given that you plan on implementing an AD provider as well, I guess it
would make sense to also implement (but maybe not expose unless there is
a common schema) a purre LDAP provider that both IPA and AD would share?

Are you going to turn this e-mail into a design page and file SSSD
tickets? Who's going to own the feature in SSSD, you, Petr or both?

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

Another reason for implementing the LDAP provider first, I guess..

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