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 with. 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 NetEngine 8000 F supports the following keychain features:
Authentication for applications
Application that requires authentication support has to quote a keychain. A keychain can have one or more key-ids. Key-id comprises of authentication algorithm and the key string (secret shared key). Each key-id is associated with send and accept 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.