No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


NE20E-S2 V800R010C10SPC500 Configuration Guide - Security 01

This is NE20E-S2 V800R010C10SPC500 Configuration Guide - Security
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Introduction to Keychain

Introduction to Keychain

Keychain provides authentication function to all the applications. The keychain also provides dynamic change of authentication keys without any packet drops.

Applications exchange authenticated packets on networks for security reasons. Authentication algorithms along with the secret shared key are used to determine whether a message sent over an insecure channel has been tampered. This type of authentication requires that the sender and the receiver share the secret key and the authentication algorithm used to authenticate the packet. Also the secret key should never be sent over the network.

If each application maintains its own set of authentication rules (authentication algorithm and shared secret key), then there are many instances in which the same set of authentication is used. This results in duplication of data and reprocessing of the authentication information. Also each of the applications uses a constant authentication key unless the administrator of the network changes the key manually. The manual change of authentication is a cumbersome procedure and during the change of keys, there can be packet drops as it is very difficult to change the keys instantaneously on all the routers.

Thus the system needs a mechanism to achieve centralization of all authentication processing and dynamic change of authentication keys without much human intervention. To achieve this functionality the keychain module is used.

The NE20E supports the following keychain features:

  • Authentication for applications

    Application that requires authentication support has to quote a keychain. A keychain can have one or multiple key-ids. Key-id comprises of authentication algorithm and the key string (secret shared key). Each key-id is associated with send and receive lifetime based on which it will be send active or receive active or both at an instant of time. Key-id that is send active at one end should be receive active at the other end. Administrator has to configure the key-ids under the keychain in such a way that both sides can communicate without any packet loss.

  • Receive Tolerance

    When the send key-id on a router changes, the corresponding receive key-id on the peer router should change instantaneously. Due to clock non-synchronization, there can be a time lag between the changes of the key-ids on the two routers. During this period, there can be packet drops because of inconsistent use of key-ids. To prevent this and to accommodate for a smooth transition from one key-id to another, a grace period is allowed during which both keys will be used. This grace period is termed as receive tolerance period, and it is applicable only to the receive keys. The receive time period will be extended by a period equal to the receive tolerance on both the start and end time of a receive key.

  • Default send-key-id

    When administrator does not configure a key-id for some interval of time, there can be a chance that there is no active send key-id. During that period, application will not be able to have authenticated communication. In order to avoid this situation there should be a default send key-id which will be always active. Any key-id in a keychain can be marked as the default send key-id. There can be only one default send key-id in a keychain. When any send key-id becomes active, the application uses the new active send key-id instead of the default send key-id. Similarly when active send key-id becomes inactive and when there is no other active send key-id, then application uses the default send key-id.

  • TCP-kind and TCP algorithm-id configuration

    TCP based applications can communicate with other vendor nodes by using the authenticated TCP connection. For authenticated communication, TCP uses TCP Enhanced Authentication Option. Currently different vendors use different kind-value to represent the TCP Enhanced Authentication Option type. So in order to communicate with other vendors, kind-value should be made configurable, so that it can be changed based on the type of vendor to which it is connected. Similarly TCP Enhanced Authentication Option has a field named algorithm-id which represents the authentication algorithm type. As algorithm-ids are not defined by IANA. Currently different vendor uses different algorithm-id to represent the same algorithm. In order to communicate with the other vendors, user has to configure the TCP algorithm-id in the keychain for the algorithms depending on the peer node type.

Updated: 2019-01-02

Document ID: EDOC1100055397

Views: 19663

Downloads: 39

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Previous Next