Subject: [Netconf] ietf-system-keychain draft module

From: Michal Vaško <[email-masked]>
Date: Tue, 02 Aug 2016 16:09:12 +0200

Hi,
I started implementing this module and I encountered some problems. I would like to know how you are planning to solve them, if they are known and being worked on, or inform you about them.

Regarding the list /keychain/private-keys/private-key, it is configurable. My guess is that the reason for this is being able to add certificate-chains to configured private keys. However, this enables the creation of instances of this list, which seems to me does not make sense and should be forbidden (or what is expected to happen in that case?). For creating new instances there are the actions generate-private-key and load-private-key, am I missing something?

As for private keys themselves, the idea probably is to keep them internally safe somewhere, so they do not appear in configuration and thus are not accidentally compromised. However, this causes major implementation issues (I know this is not considered an argument, but I believe it should not be completely neglected). Why could not be private keys part of the configuration with the NACM extension default-deny-all? My point is that other applications (using this keychain) must simply somehow get to the private key itself. Currently, the confidentiality of these keys is ensured mainly by standard file system access control. Including these keys in NETCONF datastore with default-deny-all is basically similar, but may even be considered safer than a file system. The keys could still be encrypted using a password and thus useless without it. Naturally, this password would not be part of the configuration.

Kind regards,
Michal Vasko

---

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Aug 2016 20:12:39 +0000

Hi Michal,

Thank you for reporting your early attempt to implement this module.  I implemented an earlier version of this draft for the NETCONF Call Home reference implementation [1], but that was before we moved to the keychain-based approach.  I have updated the code during the last two Hackathons, but I keep hitting compatibility issues with the crypto libraries I’m using.   I think that those issues are almost behind me now, so soon I’ll be implementing the ietf-netconf-server, ietf-ssh-server, and ietf-system-keychain modules.

Regarding your query, this is a somewhat known issue [2].  Right now I think we’re waiting for Martin to get back from PTO to respond, but my inclination is that we might have to do exactly as you say: to let the private key data be in the data model, protected by just nacm:default-deny-all.  However, there will remain the issue that some private-keys will never be visible, such as those stored within a TPM (trusted protection module).  I think this means that the “private-key” leaf needs to be mandatory false, and we’ll need some kind of warning when the private key cannot be provided.   Or we make it mandatory true, with a description statement that explains when it might fail.  Perhaps a NETCONF notification could be used for this as well.  What do you think?

[1] https://github.com/Juniper/netconf-call-home (warning: new code not checked in yet)
[2] https://github.com/netconf-wg/system-keychain/issues/2

Thanks,
Kent

On 8/2/16, 10:09 AM, "Netconf on behalf of Michal Vaško" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    
    Kind regards,
    Michal Vasko
    
    _______________________________________________
    Netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf

---

From: Michal Vaško <[email-masked]>
Date: Wed, 03 Aug 2016 08:23:03 +0200

Hi Kent,
thanks for the reply. I did not really know (or rathet have completely forgotten) about those module issue trackers, I will look at them from time to time. Regarding TPM, I personally like the idea of making the leaf non-mandatory, it seems to me it is the simplest solution.

Regards,
Michal