openconfig-keychain.yang and Protocol association

[smitharajan]

Hi,

I have two questions wrt openconfig-keychain.yang

1:I would like to know, how is the openconfig-keychain.yang going to accommodate, which protocol is using which keychain. Currently, I don't see any config or state information under openconfig-keychain.yang referring to any protocol. This is required whether we should allow no form of a key-chain or key-id, so that if no protocol is associated with the key-chain then only it is allowed. Is some development work going on around this area as I see openconfig-keychain got introduced recently? Correct me if I am wrong.

2: I see that start-time / end-time accepts nano seconds only relative to UNIX epoch..Any plan to accommodate any other time format?

Thanks, Smitha

[oscargdd]

Hi Smitha,

 The first step was to add the support for key-chain. Now, every protocol will be extended to use the key-chain as part of its authentication configuration. So, expect updates in the next weeks.

[smitharajan]

Thanks Oscar for your reply.

One more question, will there be config under keychain in openconfig-keychain.yang on which list of protocols using that keychain or will it be configured under protocol yang only?

Thanks, Smitha

[smitharajan]

Hi,

Can somebody explain the significance of why secret-key has to be encrypted format? Is there any mechanism in place to maintain the (key , encryption algorithm ) used to encrypt this secret-key to be used?

leaf secret-key { type string; description "Authentication key supplied as an encrypted value. The system should store and return the key in encrypted form."; }

[dplore]

It is customary to use an encrypted string rather than a plain text format. Here are a couple of examples of support in vendor native CLI for reference:

JunOS: https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/ref/statement/authentication-key-chains-edit-security.html IOS XR: https://www.cisco.com/en/US/docs/routers/xr12000/software/xr12k_r3.9/security/command/reference/sr39kcm.html#wp1015491

On Mon, Feb 28, 2022 at 8:58 AM smitharajan @.***> wrote:

Hi,

Can somebody explain the significance of why secret-key has to be encrypted format? Is there any mechanism in place to maintain the (key , encryption algorithm ) used to encrypt this secret-key to be used?

leaf secret-key { type string; description

"Authentication key supplied as an encrypted value. The system should store and return the key in encrypted form."; }

— Reply to this email directly, view it on GitHub https://github.com/openconfig/public/issues/587#issuecomment-1054462105, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMCGM5V2QY4UHIIB6YFRRLU5OSTNANCNFSM5OUAXZJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[sulrich]

both implementations (as well as others) also allow for plain-text configuration of the key as well. the encrypted password is typically used for configuration restoration and commonly follows the vendor's specific encoding and foibles to allow for config restoration, etc.

for initial configuration, it may not be feasible or practical to manage these encrypted keys consistently. having a mechanism to provide a plain-text key seems useful. this plain-text leaf could be restricted from retrieval in the state container using whatever mechanisms the implementation provides for such a restriction. or, a vendor may simply opt to never present this within the context of the state container based on whatever policy the implementation provides

[sulrich]

@m26singhvi for ref

[smitharajan]

@sulrich: yes i do agree to provide support for plain-text.

@oscargdd: Can you please let me know is there any update at protocol yangs to make use of this keychain infra?

Thanks, Smitha

[rgarunkumar]

Without having the option to configure plain-text, oc-keychain might not be usable for initial configuration. I think every vendor provides plain-text way of configuring the keys.

Some examples:

Cisco: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/security/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide_7x_chapter_010000.html -> Refer "key-string [encryption-type] text-string" with encryption-type = 0(plain-text)

Juniper: https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/user-access-root-password.html -> Refer 'plain-text-password' config option.

Arista: https://www.arista.com/en/um-eos/eos-data-plane-security#xx1211038 -> Refer "0Specifies that an UNENCRYPTED key will follow."

[m26singhvi]

There is a CRYPTO_NONE option available https://github.com/openconfig/public/blob/master/release/models/keychain/openconfig-keychain-types.yang which I think can be used to the crypto-algorithm value to signify unencrypted key.

[rgarunkumar]

My understanding is:

• CRYPTO_TYPE(which includes CRYPTO_NONE) specifies the 'crypto-algorithm' to be used by the protocol/application when they do their authentication i.e. on the protocol packets.
• Regarding the encryption for the secret-key means that how it is stored in the vendor's system - typically vendors store the keys in their system using some encryption techniques.

So, I think we can't use CRYPTO_TYPE(which includes CRYPTO_NONE) to specify the encryption technique used by the vendor.

[m26singhvi]

As per the following snippet from the key chain model, crypto-algorithm is associated with the key and not with the protocol.

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).";
    }

[rgarunkumar]

Hi @m26singhvi ,

Even though the crypto-algorithm is associated with the key, the keychain would ultimately be associated to a protocol. So when the protocol uses the keychain, it not only gets the active keys, it also gets the crypto-algorithm corresponding to that active key.

BTW, the description of the 'crypto-algorithm' clearly states that it is to be used by the protocols. "Note that not all cryptographic algorithms are available in all contexts (e.g., across different protocols)."

Infact the 'crypto-algorithm' specified under the 'key' aligns nicely with some of the vendor implementations.

Example: JunOS: https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/ref/statement/authentication-key-chains-edit-security.html authentication-key-chains { key-chain key-chain-name { description text-string; key key { algorithm (md5 | hmac-sha-1); <---- [ARUN] This does not refer to how the keys are stored. This algo is used by the protocol key-name authentication-key-name; options (basic | isis-enhanced); secret secret-data; start-time yyyy-mm-dd.hh:mm:ss; } tolerance seconds; } }

Cisco: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/security/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_Security_Configuration_Guide_7x_chapter_010000.html

Under 'key' config: cryptographic-algorithm {HMAC-SHA-1 | HMAC-SHA-256 | HMAC-SHA-384 | HMAC-SHA-512 | MD5} Purpose: Configures the OSPFv2 cryptographic algorithm to be used for the specified key.

Thanks, Arun.

[m26singhvi]

Sure, thanks @rgarunkumar. I raised a separate issue - https://github.com/openconfig/public/issues/785 to understand better about this.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.