What is crypto-algorithm for in openconfig-keychain model ?
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.
Please feel free to reopen if @morrowc 's response needs clarification.
I would like to revisit this decision.
For dataplane encryption configuration, OC defines the algorithm used for encryption with the protocol that is performing the encryption. For example:
MACSec: /macsec/mka/policies/policy/config/macsec-cipher-suite is used to configure which encryption algorithm (cipher-suite) is used to encrypt data packets.
ISIS: /network-instances/network-instance/protocols/protocol/isis/levels/level/link-state-database/lsp/tlvs/tlv/authentication/state/crypto-type
IKE, we are introducing (via openconfig/public#1441):
/network-instances/network-instance/security/ike/child-sa//ipv4/security-associations/security-association/state/encryption-algorithm
We need to define an algorithm used to encrypt the key in a keychain. This leaves only:
/keychains/keychain/keys/key/config/crypto-algorithm. It's also sensible this leaf describes the encryption of the key because it appears in the same container where the key itself is defined. (/keychains/keychain/keys/key/config).
I will add text to the description of crypto-algorithm to increase the clarity of the intent.
Here are two implementations which roughly follow the existing OC schema of keychain with key algorithm and macsec with it's separate encryption algorithm.
Cisco IOS XR
- Creating a MACsec keychain
- Creating a user-defined MACsec policy
- Applying MACsec configuration on physical interfaces
! datapath encryption
macsec-policy <policy-name>
cipher-suite GCM-AES-256
!
! keychain example, using pre-shared keys
key chain <key-chain-name> macsec
key <key-id>
key-string <hex-string> cryptographic-algorithm {aes-128-cmac | aes-256-cmac}
!
interface Te0/3/0/1/4
macsec psk-keychain mac_chain policy mac_policy
Juniper JunOS macsec (static with pre-shared keys example here)
#create a macsec security association
[edit]
set security macsec connectivity-association ca1 security-mode static-cak
set security macsec connectivity-association ca1 cipher-suite gcm-aes-xpn-128
#create a keychain using pre-shared keys
[edit]
set security authentication-key-chains key-chain macsec_key_chain key 1 secret 01112233445566778899aabbccddeeff
set security authentication-key-chains key-chain macsec_key_chain key 1 key-name 01112233445566778899aabbccddeefe
#Associate the newly created keychain with a MACsec connectivity association
set security macsec connectivity-association ca1 pre-shared-key-chain macsec_key_chain
#Apply the security association to an interface
set security macsec interfaces ge-0/0/1 connectivity-association ca1
We will need another key which uses this crypto algorithm to encode secret-key, right ? We don't have that key leaf; even if we add it; we will need another key for encoding that and so on ...
Here's how I think OC should map to EOS:
EOS Key configuration
!
management security
password encryption reversible aes-256-gcm
!
tacacs-server key 8a $kUVyoj7FVQ//yw9D2lbqjA==$kxxohBiofI46IX3pw18KYQ==$DOOM0l9uU4TrQt2kyA7XCKtjUA==
OC equivalent JSON
{
"keychains": {
"keychain": [
{
"config": {
"name": "keychain1"
},
"keys": {
"key": [
{
"config": {
"crypto-algorithm": "AES_256_CMAC",
"key-id": "1",
"secret-key": "$kUVyoj7FVQ//yw9D2lbqjA==$kxxohBiofI46IX3pw18KYQ==$DOOM0l9uU4TrQt2kyA7XCKtjUA=="
},
"key-id": "1"
}
]
},
"name": "keychain1"
}
]
},
"system": {
"aaa": {
"server-groups": {
"server-group": [
{
"config": {
"name": "TACACS"
},
"name": "TACACS",
"servers": {
"server": [
{
"address": "192.0.2.1",
"config": {
"address": "192.0.2.1"
},
"tacacs": {
"config": {
"port": 49,
"keychain-name": "keychain1" # note: this path doesn't actually exist in OC today, but would be a leafref to keychain-name
}
}
}
]
}
}
]
}
}
}
}
IMO crypto-algorithm has nothing to do with how secret-key is encrypted in the configuration (i.e. doesn't affect the value that is returned when reading the config).