Common access card (two-factor) authentication
Overview
A common access card (CAC) is a United States Department of Defense (DoD) smart card for multifactor authentication. CACs are issued as standard identification for active-duty military personnel, reserve personnel, civilian employees, non-DoD government employees, state employees of the National Guard, and eligible contractor personnel. In addition to its use as an ID card, a CAC is required for access to government buildings and computer networks.
Two-factor authentication
Part of the requirement necessary to satisfy the Federal Government Certification is two-factor authentication. Two-factor authentication is the redundant authentication of the CAC. For example, the CAC satisfies two-factor authentication by mandating that you have both the physical card and know the pin number associated with the card.
To provide support for CAC authentication, the requirement for the network is the establishment of SSH connections. Two-factor authentication constitutes authentication based on public key or certificate and username/password on the switch.
Restrictions
The following are some of the restrictions when working with CAC authentication:
Support is not provided for any other management connections other than SSH.
Support is not provided for any switch acting as CAC SSH client.
Support is not provided for public-key authentication based on DSA and ECDSA public keys.
The maximum number of client public keys that can be installed is 10.
When there is failure in any one of the authentication methods, the SSH connection will not be established.
The following table lists the invalid authentication methods for SSH.
login
enable
public-key
certificate
public-key
two-factor-certificate
certificate
public-key
certificate
two-factor-public-key
two-factor-public-key
certificate
two-factor-public-key
two-factor-certificate
two-factor-certificate
public-key
two-factor-certificate
two-factor-public-key
Expected behaviors
With include-credentials command
When the command
include-credentialsis enabled, public keys are stored both in configuration and flash files.When the command
[no] include-credentialsis executed, the client public key is stored only in the flash.When the command
[no] include-credentials store-in-configis executed, behavior is then based on the user entry made with the pop-up message.The command
HP-switch(config)# [no] include-credentials store-in-configwill display a message similar to:This will remove any switch passwords and inactive SSH authorized keys from all configuration files. This will also restore the functionality to store only a single set of passwords and authorized keys on the switch. Continue (y/n)? y The SSH authorized keys associated with the active configuration will be deleted. Would you like to retain these as the switch global SSH authorized keys (y/n)? y If the above option entered is “y”, then the client public key will be available in the flash but not in the config. If the above option entered is “n”, then the client public key is neither available in the flash nor in the config.
Zeroization
When the zeroization command HP-Switch(config)#
crypto key zeroize ssh-client-key is executed, the client
public keys will be zeroized in the flash.
HP-2920-24G(config)# crypto key zeroize ssh-client-key The manager key pair will be deleted, continue (y/n)? y The commanderase all zeroizewill also perform the zeroization of the key files in the flash. The commanderase allwill only delete the key files from flash.
Switch is moved to/from enhanced security mode
Since the secure mode change goes through zeroization, the client keys are deleted and the switch will revert to the default configuration without any client keys on the switch.
Attempting to configure a two-factor authentication method with no public key or username configured
If, during the download of the configuration file, the username and/or public key is not configured, then no action will be taken. A warning message will display similar to:
username and/or public key is not configured.
An RMON will be logged with the message that the authentication method is set to two-factor with some configuration missing.
When the user tries to connect using SSH, the connection will fail.
Deletion of the public key and/or username when the authentication method is set to two-factor authentication
For the following three scenarios:
After the authentication method is set to two-factor, if the client public keys are deleted while the usernames still exists on the switch...
After the authentication method being set to two-factor, if the username is deleted the public key exists on the switch...
When both the public key and usernames are deleted while the authentication method is being set to two-factor authentication...
The new SSH connection will fail at either the public key authentication and/or username/password authentication. RMON will be logged with appropriate message on the switch.
![[NOTE: ]](images/note.gif) | NOTE: An alternative solution is to block the deletion of the public key and/or username when the authentication method is set as two-factor authentication. With this approach, the impact of many configurations need to be taken care cautiously since the username/password can be configured through many interfaces such as SNMP, REST, WebUI, Menu, setup mgmt.-interfaces, and include-credentials. |
Authentication method re-configured at run time
If the authentication method is reconfigured at run time, the modified authentication method will be applied when the new connection will be established.