NSO confusing device encryption with its own tailf encryption

[samuel.coome@secunetics.com]

I'm attempting to create a template for creating an NSO local user. For the secret, I want to copy paste and already encrypted value from an existing device to be used. The issue is that when I see the dry-run, NSO think's the encrypted value is using tailf encryption and thinks it needs to decrypt it. NSO does not realize this is using the devices encryption and should be sent to the device "as-is". Is there a way to send/store this value without NSO attempting to decrypt it?

sam@nso# show running-config devices template nso-user
devices template nso-user
 ned-id cisco-ios-cli-6.67
  config
   username nso
    algorithm-type sha256
    secret type 8
    secret secret $8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM
   !
  !
 !
!

sam@nso# config
Entering configuration mode terminal

sam@nso(config)# devices device device1 apply-template template-name nso-user
apply-template-result {
    device device1
    result ok
}

sam@nso(config)# commit dry-run outformat native
native {
    device {
        name device1
        data 
             ! meta-data :: /secret :: maapi-encrypted
             username nso algorithm-type sha256 secret 8 $8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM
    }
}

[vleijon]

Try prefixing with $0$, that might help.

[samuel.coome@secunetics.com]

Hi Viktor, I had tried that, as a colleague said that works for using special characters in NSO, however it does not work for me here.

sam@nso(config)# devices device device1 apply-template template-name nso-user
apply-template-result {
    device device1
    result ok
}

sam@nso(config)# commit dry-run outformat native
native {
    device {
        name device1
        data username nso secret 8 $0$$8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM
    }
}

sam@nso(config)# show full-configuration devices template nso-user
devices template nso-user
 ned-id cisco-ios-cli-6.67
  config
   username nso
    secret type 8
    secret secret $0$$8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM
   !
  !
 !
!
sam@nso(config)# commit
Aborted: External error in the NED implementation for device device1: command: username nso secret 8 $0$$8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM
: ERROR: The secret you entered is not a valid encrypted secret.
To enter an UNENCRYPTED secret, do not specify type 8 encryption.
When you properly enter an UNENCRYPTED secret, it will be encrypted.

It looks as though NSO thinks the it is a string that starts with $0$, instead of using $0$ to denote that what follows should be the string and to not interpret what follows as tailf:encryption.

[rogaglia]

hi Samuel,

I would configure the target device with your target password and do a Sync-from to check how the NED is representing it. The template should have the same format. Be aware of some changes in recent releases on how to deal with passwords that start with the "$" character.

From NSO 5.5 CHANGE file:

- ncs: Encrypted strings that is of type tailf:aes-256-cfb-128-encrypted-string starting with "$", are now
accepted as input.
This reverts the earlier change that rejected such input, as this caused
issues with how some devices handles strings.

(ENG-24718)

[samuel.coome@secunetics.com]

Hi Rogaglia,

I'm using NSO version 5.3.1.1 currently, not certain how large the difference between the two are. NSO 5.3.1.1 does accept strings starting with "$", but it is not a tailf:aes-256-cfb-128-encrypted-string.

I attempted what you said, configuring the username on the device, and then performing a sync-from. Below are my results.

user1@nso(config)# devices device my_device

user1@nso(config-device-my_device)# sync-from

user1@nso(config-device-my_device)# show full config username nso
devices device my_device
 config
  username nso secret 8 $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw
 !
!

user1@nso(config-device-my_device)# live-status exec any "show runn | in username nso"
result
username nso secret 8 $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw
my_device#

user1@nso(config)# devices template local-user-test ned-id cisco-ios-cli-6.67 config

user1@nso(config-config)# username nso secret type 8 secret $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw

user1@nso(config-username-nso)# commit

user1@nso(config-username-nso)# show full
devices template local-user-test
 ned-id cisco-ios-cli-6.67
  config
   username nso
    secret type 8
    secret secret $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw
   !
  !
 !
!

user1@nso(config-username-nso)# top

user1@nso(config)# devices device my_device apply-template template-name local-user-test
apply-template-result {
    device my_device
    result ok
}

user1@nso(config)# commit dry-run outformat native
% No modifications to commit.

user1@nso(config)# no devices device my_device config username nso

user1@nso(config)# commit no-networking
Commit complete.

user1@nso(config)# devices device my_device apply-template template-name local-user-test
apply-template-result {
    device my_device
    result ok
}

user1@nso(config)# commit dry-run outformat native
native {
    device {
        name my_device
        data ! meta-data :: /secret :: maapi-encrypted
             username nso secret 8 $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw
    }
}

user1@nso(config)#

So NSO doesn't know the difference. In the trace NSO fails to maapi decrypt, and sends the string as is, so it works. It seems strange though that we have to rely on the failure to decrypt for proper function (from how I understand it). The other thing is since NSO understands $8$ to be tailf encryption, and device encryption is also stored as $8$ (as seen above), this means that on a rollback where NSO configures the username and secret to what is was (previously stored on the device), NSO thinks the string is tailf encrypted and tries to decrypt it (fails again, and sends string as is - so no issue yet).

So it fails because it's AES in NSO and SHA256 on the device, but if the output of the hash ever is matched by AES, then it would "decrypt" and send some random value to the device. So I don't think it will probably be a problem, as md5 and scrypt use a difference $num$, and I'm guessing SHA256 will never output a base-64 value for AES to accidentally recognize it and "decrypt" it. 

I'm trying to figure out if this is an issue to be concerned about, and if I'm fully wrapping my head around it. Thought it'd be easiest to just tell NSO that it's a string and not tailf encrypted.