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

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" <netconf-bounces@ietf.org on behalf of mvasko@cesnet.cz> wrote:

    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

    _______________________________________________
    Netconf mailing list
    Netconf@ietf.org
    https://www.ietf.org/mailman/listinfo/netconf