On 4.3.2014 21:25, 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@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?

Where are we going to store private keys for DNS services (for vault)?

Can the vault approach work for Kerberos master key? If not, shouldn't we
design something universal instead of deferring it again and again?

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

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

Actually an idea came to mind that might work well enough.

We could store the symmetric key wrapped itself.
???

The wrapping would be done using a public key per DNS server.
Public keys for DNS servers would be generated via certmonger in the
usual way.
I don't understand, maybe it is too late for me :-)

Where will the private key be stored?

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.

Please correct me if I'm wrong.
I guess that you mean something like
http://www.freeipa.org/page/V4/Password_Vault#Service_Workflows , right?

--
Petr^2 Spacek

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to