09-12-2023 01:41 AM
Hello,
I developed an NSO service to configure a keychains on CiscoXR router "CiscoXR 7.4.2 version". NED is not allowing me to send the keystring as cleartext.
'''
<keychain>
<chain-name>{chain_name}</chain-name>
<keys>
<key>
<key-id>1</key-id>
<key-string>
<key-string>{keystring}</key-string>
<encrypt-type>type6</encrypt-type>
</key-string>
'''
NED restricting me to send encryption type6 or type7. but when i try to set it to type6 or type7, i found it sent to the router only in type7!
Is there any work arounds that makes me able to send the keystring as type6?
I also tried to write a python function that takes the keystring as plaintext and the master-key and encrypt it to calculate the type6 keystring. Any help to fix it?
My python code
def encrypt_cbc(): secret = "0123456789abcdef" msg = "1234567890123456" iv = os.urandom(16) #iv = "7bde5a0f3f39fd658efc45de143cbc94" cipher = AES.new(str.encode(secret), AES.MODE_CBC, iv) cipher_text = cipher.encrypt(str.encode(msg)) cipher_text = base64.b16encode(cipher_text) cipher_text = str(cipher_text) cipher_text = cipher_text.replace("'", "", 2) cipher_text = cipher_text.replace("b", "") print(cipher_text.lower())
Expected to get: 4a60445b64695661635f67524a59575f55615047605d624b4e64605e654f4e56584d6062424d68514e62414142
But the code gives: 6cfdab2dcd7308cdb14a629a14b82597
09-19-2023 02:30 AM
Hello Cohult,
Proprietary passwords expect either clear text starting with "!" and the server will hash it or the hashed value of the passwords.
Case1: cleartext starting with "!"
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> <edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <target> <candidate /> </target> <test-option>test-then-set</test-option> <error-option>rollback-on-error</error-option> <config> <keychains xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-lib-keychain-cfg"> <keychain> <chain-name>test</chain-name> <keys> <key> <key-id>1</key-id> <key-string> <key-string>!test</key-string> </key-string> </key> </keys> </keychain> </keychains> </config> </edit-config> </rpc>
when show running-config on router it appears as type7 encrypt not type6:
key chain test
key 1
key-string password6 15060E1F10
Case2: hashed value of password
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> <edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <target> <candidate /> </target> <test-option>test-then-set</test-option> <error-option>rollback-on-error</error-option> <config> <keychains xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-lib-keychain-cfg"> <keychain> <chain-name>test</chain-name> <keys> <key> <key-id>1</key-id> <key-string> <key-string>476158595763455745625f515b515f5f5a5b565a655a4445414142</key-string> </key-string> </key> </keys> </keychain> </keychains> </config> </edit-config> </rpc>
when show running-config on router it appears as type6:
key chain test
key 1
key-string password6 476158595763455745625f515b515f5f5a5b565a655a4445414142
So what is the ideal case to handle this issue?
09-19-2023 08:59 AM
Hi,
Looking at the Cisco-IOS-XR-lib-keychain-cfg.yang model that seems to match the version you are using:
container keys {
description
"Configure a Key";
list key {
key "key-id";
description
"Key Identifier";
container key-string {
description
"Configure a clear text/encrypted Key string ";
leaf key-string {
type xr:Proprietary-password;
description
"Key String";
}
leaf encrypt-type {
type Key-encryption;
default "type7";
description
"Encryption Type";
}
}
...
The default "encrypt-type" is "type7", and as you are not setting the "encrypt-type" leaf in your template, the default value will be used, i.e. "type7" (not "type6").
09-19-2023 09:36 AM
I missed type it while replying, but it included in the template as type6. Do you know how to make NSO encrypt type6 passwords instead of type7?
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4">
<edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<target>
<candidate />
</target>
<test-option>test-then-set</test-option>
<error-option>rollback-on-error</error-option>
<config>
<keychains xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-lib-keychain-cfg">
<keychain>
<chain-name>test</chain-name>
<keys>
<key>
<key-id>1</key-id>
<key-string>
<key-string>476158595763455745625f515b515f5f5a5b565a655a4445414142</key-string>
<encrypt-type>type6<encrypt-type/>
<key-string>
</key>
</keys>
</keychain>
</keychains>
</config>
</edit-config>
</rpc>
09-19-2023 11:33 AM
NSO will not encrypt the string configured for the "key-string" leaf. The XR device will encrypt it.
09-19-2023 05:18 AM
@emilgamal I think the best option is to open a TAC case. To me this looks like a bug - sending payload like below resulting in type 7 hashed passwords on a box where AES password encryption is enabled is just wrong behaviour.
<keychains xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-lib-keychain-cfg">
<keychain>
<chain-name>test</chain-name>
<keys>
<key>
<key-id>1</key-id>
<key-string>
<key-string>!thecleartextpassword</key-string>
<encrypt-type>type6</encrypt-type>
</key-string>
</key>
</keys>
</keychain>
</keychains>
09-19-2023 02:25 PM
Yes I agree it is a bug, I tried the same template with XR 7.5.1 and the same NSO version 5.5.4.1
<device> <name>R6</name> <config> <key xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-um-key-chain-cfg"> <chains> <chain> <key-chain-name>test</key-chain-name> <keys> <key> <key-name>1</key-name> <key-string> <password6>!test</password6> </key-string> </key> </keys> </chain> </chains> </key> </config> </device>
RP/0/RP0/CPU0:R6#show running-config key chain
Tue Sep 19 21:18:20.457 UTC
key chain test
key 1
key-string password6 615e48655e424a475466484c5368506358506755455b514f414142
!
!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide