[Freeipa-devel] DNSSEC design page: key wrapping

[Petr Spacek]

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?

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?

That would mean that, after all, we just need to provide some blob as key 
wrapping key :-) (Generated with care it deserves etc.)


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.


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


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? :-)

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.

-- 
Petr^2 Spacek