What is crypto-algorithm for in openconfig-keychain model ?
Closed this issue · 3 comments
In openconfig-keychain model,
leaf crypto-algorithm {
type identityref {
base oc-keychain-types:CRYPTO_TYPE;
}
description
"Cryptographic algorithm associated with the key. Note that not all cryptographic
algorithms are available in all contexts (e.g., across different protocols).";
}
What is this for, as this provided for every key which is configured in the keychain and can be different in the same keychain.
My understanding is this crypto type specifies the encryption in which the key is configured. Is that correct ?
To provide a bit more context: One obvious use case for the openconfig-keychain model could be to implement the configuration frontend for a key management system for TCP AO (RFC5925). The cryptographic algorithm in this context could refer to (1) the specific the Message Authentication Code (MAC) to be used to hash TCP segments. Alternatively, the algorithm could be (2) used by an OpenConfig speaker to convey (to the receiver) the algorithm used to encrypt the keying information (namely, key-id in the model). Which is intended?
<howdy - comment snipe>
The top of the keychain yang model has this text:
description "This module describes a YANG model for keychain configuration and management. These keys can be changed frequently to increase security in long-lived connections. A keychain can be used for authenticaion in a number of scenarios, including in routing protocols (e.g. BGP, IS-IS, OSPF). A keychain provides a solution for storing a number of different keys, each key string value is associated with a specific key id, name, the lifetime that the key is valid and an encryption algorithm. This model defines a central location for defining named keychains, which may be then referenced by other models such as routing protocol management.";
this, to me, sounds like a standard keychain/table setup vendors normally implement for MACSEC, ISIS or OSPF autnentication schemes. Effectively this is a registry of:
keyid key valid-use-times algorithm
1 fo0b4r Jan 1 1970 - Jan 1 heat-death-of-universe chachacha
I believe the intent is to permit you to have 1 location to store all of this data, and reference the key table content later in other use-cases (your isis authentication, or macsec key management, etc).
So, in joshpfosi's text I believe this makes sense as #1 not #2.