The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The GET VPN Support with Suite B feature adds support of the Suite B set of ciphers to Cisco Group Encrypted Transport (GET) VPN. Suite B is a set of cryptographic algorithms that includes Galois Counter Mode Advanced Encryption Standard (GCM-AES) as well as algorithms for hashing, digital signatures, and key exchange.
Suite B for IP security (IPsec) VPNs is a standard whose usage is defined in RFC 4869, Suite B Cryptographic Suites for IPsec. Suite B provides a comprehensive security enhancement for Cisco IPsec VPNs, and it allows additional security for large-scale deployments. Suite B is the recommended solution for organizations requiring advanced encryption security for the wide-area network (WAN) between remote sites.
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
All key servers (KSs) and group members (GMs) on which you want to enable this feature must be running GET VPN software version 1.0.4 or higher. You should use this feature only after all devices in the GET VPN network are upgraded to GET VPN software versions that support this feature. This feature provides a command that you use on the KS (or primary KS) to check whether all devices in the network are running versions that support Suite B. For more information, see the "Ensuring That GMs Are Running Software Versions That Support Suite B" section.
When they are using a GCM policy or a Galois Message Authentication Code (GMAC) traffic encryption key (TEK) policy, all cooperative KSs for a group must use an access control list (ACL) that has identical ACL entries (ACEs) in the identical order. If not, GMs that register to separate KSs cannot encrypt and decrypt correctly after downloading the policy. This is because with Suite B, an SPI (security parameter index ID that is associated with the TEK) is generated for each ACL entry and is unique to each ACL entry.
You cannot reorder entries in an existing ACL. So if you are using a GCM or GMAC TEK policy and must update the ACL on each KS so that it has identical entries in the identical order on each KS, you must remove the ACL from each secondary KS, then create a new ACL on the primary KS, then copy it to the secondary KSs, and then enter the crypto gdoi ks rekey command on the primary KS to trigger a rekey across the GET VPN network.
You remove an ACL by using the no form of the ip access-list command (or if you are using IPv6, the no form of the ipv6 access-list command).
Information About GET VPN Support with Suite B
Suite B is standardized by the National Security Agency (NSA) and the National Institute of Standards and Technology (NIST). The GET VPN Support with Suite B feature allows these cryptographic algorithms to be used with GDOI and GET VPN in various ways, including the use of SHA-2/HMAC-SHA-2 and AEC-GCM/AES-GMAC.
Secure Hash Algorithm 2 (SHA-2) is a set of cryptographic hash functions (SHA-224, SHA-256, SHA-384, and SHA-512) designed by the NSA and published by the NIST as a U.S. Federal Information Processing Standard (FIPS). SHA-2 includes many changes from its predecessor, SHA-1. SHA-2 comprises a set of four hash functions with digests that are 224, 256, 384, or 512 bits.
HMAC is a mechanism for message authentication using iterative cryptographic hash functions. HMAC-SHA-2 is HMAC used in combination with the SHA-2 version (SHA-224, SHA-256, SHA-384, and SHA-512) iterative cryptographic hash functions in combination with a secret shared key in IPsec. These combinations are called HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. These algorithms can be used as the basis for data origin authentication and integrity verification mechanisms for the authentication header (AH) (although not supported by GET VPN), encapsulating security payload (ESP), IKE, and IKEv2 protocols, and also as pseudo-random functions (PRFs) for IKE and IKEv2.
AES using GCM (AES-GCM) is an encryption algorithm for IPsec. AES using Galois Message Authentication Code (AES-GMAC) is a message integrity algorithm also used for IPsec.
The GET VPN Support with Suite B feature lets you use SHA-2 and HMAC-SHA-2 (HMAC-SHA-256, 384, and 512) as the hash and signature algorithms. SHA-2 and HMAC-SHA-2 with 256, 384, & 512-bit keys are used in
GDOI registration using IKEv1 as the hash algorithm as described in Section 3.2 (authentication between KSs and GMs) of RFC 6407, The Group Domain of Interpretation.
The key encryption key (KEK) rekey policy to hash the rekey message for authentication of the rekey message from the KS as well as authentication of the acknowledgment message from the GM.
The TEK IPsec policy as HMAC-SHA-2 for IPsec SA integrity checking.
AES-GCM (AES-GCM-128, 192, and 256) and AES-GMAC (AES-GMAC-128, 192, and 256) cryptographic algorithms with 256, 384, and 512-bit keys are used in TEK IPsec policies as IPsec SA encryption and integrity algorithms. GCM is used for encryption and integrity, while GMAC is used for integrity only.
RFC 4869 describes four sets of cryptographic algorithms for use with IKE and IPsec. When configured, any of these sets will comply with Suite B. Each set consists of an encryption algorithm, a digital signature algorithm, a key agreement algorithm, and a hash or message digest algorithm:
Suite-B-GCM-128: Provides ESP integrity protection and confidentiality using 128-bit AES-GCM (see RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)). Use this suite or Suite-B-GCM-256 when ESP integrity protection and encryption are both needed.
Suite-B-GCM-256: Provides ESP integrity protection and confidentiality using 256-bit AES-GCM (see RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)). Use this suite or Suite-B-GCM-128 when ESP integrity protection and encryption are both needed.
Suite-B-GMAC-128: Provides ESP integrity protection using 128-bit AES-GMAC (see RFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH) but does not provide confidentiality. Use this suite or Suite-B-GMAC-256 only when there is no need for ESP encryption.
Suite-B-GMAC-256: Provides ESP integrity protection using 256-bit AES-GMAC (see RFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH) but does not provide confidentiality. Use this suite or Suite-B-GMAC-128 only when there is no need for ESP encryption.
Cisco software contains the ability to configure any of these algorithms. The GET VPN Support with Suite B feature allows GET VPN to use these algorithms.
In GET VPN, a counter-based mode of operation (for example, ESP-GCM-AES) requires that an initialization vector (IV) is never reused with a group key. Therefore, this feature provides a method to allow a KS to allocate to each GM (for each interface) a unique sender identifier (SID) for IV construction.
In Suite B, TEK IPsec policies that are used as IPsec SA encryption and integrity algorithms require management of unique pools of SID values on KSs to distribute those unique SID values (GMSIDs) to GMs. Each cooperative KS must have a distinct pool of GMSIDs to allocate. Each KS configures unique KS SIDs (KSSIDs) to configure these SID pools.
A SID space is divided into two parts: a KSSID part and a GMSID part. Therefore, a SID is a concatenation of a KSSID and a GMSID, where the KSSID is the KS portion of a SID, and the GMSID is the GM portion of the SID. A SID is formed by the following bits:
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 (bits) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KSSID | GMSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this example, each KSSID (0 to 127) has 217 (131,072) GMSIDs, which are dynamically assigned to each registering GM.
A GM uses GMSIDs to form a unique 64-bit IV for each packet sent with a given key when using AES-GCM or AES-GMAC. An IV is formed by the following bytes:
0 1 2 3 4 5 6 7 (bytes) +---+---+---+---+---+---+---+---+ | SID | SSIV | +---+---+---+---+---+---+---+---+
The sender specific IV (SSIV) is a packet counter.
The group size is the length of the SID space allocation for KSSIDs as well as GMSIDs that are reserved to a KS for distribution to GMs. Available group sizes are small (8, 12, or 16 bits), medium (24 bits, which is the default), and large (32 bits). Medium is sufficient for nearly all networks.
You should use a large group size only if you must strictly adhere to the requirement in section A.5, “Key/IV Pair Uniqueness Requirements from SP 800-38D” of the publication Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program in which GET VPN used in conjunction with Suite B must have at least 232 unique possible “module names” (SIDs).This publication is issued and maintained by the NIST and the Communications Security Establishment Canada (CSEC).
For example, in a large group size with one KS, the SID is 32 bits, there are 512 KSSID values (in the range of 0 to 511), and each has 8,388,607 GMSIDs to distribute to registering GMs. With a large group size, use the following KSSID assignment guidelines to configure KSSID ranges:
KS |
1 KS (no cooperative KSs) |
2 cooperative KSs |
3 cooperative KSs |
4 cooperative KSs |
---|---|---|---|---|
KS1 |
0 - 511 |
0 - 255 |
0 - 127 |
0 - 63 |
KS2 |
— |
256 - 511 |
128 - 255 |
64 - 127 |
KS3 |
— |
— |
256 - 383 |
128 - 191 |
KS4 |
— |
— |
384 - 511 |
192 - 255 |
KS5 |
— |
— |
— |
256 - 319 |
KS6 |
— |
— |
— |
320 - 383 |
KS7 |
— |
— |
— |
384 - 447 |
KS8 |
— |
— |
— |
448 - 511 |
If you plan to expand the cooperative KS network to include more KSs, while you are initially configuring the original KS or KSs, use the column in the above table with the anticipated number of KSs in the network so that you can add the new KS or KSs later.
You should use a small (8-, 12-, or 16-bit) group size only in well-understood cases where strict interoperability with SID lengths of 8, 12, and 16 bits is required according to RFC 6054, Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic. If such interoperability is needed, you must be careful when designing the network, because the number of SIDs per group is severely limited (and therefore, the number of KSs and GMs in a group is severely limited). Following are the limitations for a small group size:
SID length |
KSSIDs (total KSs) |
GMSIDs per KSSID |
GMSIDs (total GMs) |
Possible number of GM registrations for one KS (after assigning KSSIDs to all KSs evenly) |
|||
---|---|---|---|---|---|---|---|
— |
— |
— |
— |
1 KS |
2 KSs |
4 KSs |
8 KSs |
8 bits |
2 |
128 |
255 |
320 |
96 |
— |
— |
12 bits |
4 |
1,024 |
4,095 |
3,840 |
1,792 |
768 |
— |
16 bits |
16 |
4,096 |
65,535 |
64,512 |
31,744 |
15,360 |
7,168 |
You should plan ahead to assign a certain number of initial GDOI KS identifiers (KSSIDs) to each KS based on the configured group size, number of KSs, number of GMs, number of GMs per KS, and any future expansion of KSs or GMs (or both).
When there are multiple cooperative KSs in a GDOI group, each KS must have a unique set of KSSID values to ensure that a registering GM never receives the same SID as another registering GM in the group. Therefore, you should plan how you will assign KSSIDs across cooperative KSs in advance, while considering the number of cooperative KSs and if cooperative KSs will be added later. If none will be added, you can assign all available KSSIDs across all KSs. If cooperative KSs will be added, you should reserve some KSSIDs to assign to those KSs when you add them to the network.
You can reassign KSSIDs; however, if KSSIDs that are already used by a KS to distribute GMSIDs are removed from the KS, the group will reinitialize (meaning that all GMs will be forced to re-register, and TEK IPsec SAs will be rekeyed to reset the used KSSIDs) without traffic loss. To avoid this group reinitialization, use the guidelines in the following table (which uses the default group size of medium):
|
1 KS (no cooperative KSs) |
2 cooperative KSs |
3 cooperative KSs |
4 cooperative KSs |
---|---|---|---|---|
KS1 |
0 - 127 |
0 - 63 |
0 - 31 |
0 - 15 |
KS2 |
— |
64 - 127 |
32 - 63 |
16 - 31 |
KS3 |
— |
— |
64 - 95 |
32 - 47 |
KS4 |
— |
— |
96 - 127 |
48 - 64 |
KS5 |
— |
— |
— |
65 - 80 |
KS6 |
— |
— |
— |
81 - 95 |
KS7 |
— |
— |
— |
96 - 112 |
KS8 |
— |
— |
— |
113 - 127 |
If you plan to expand the cooperative KS network to include more KSs, when initially configuring the original KS (or KSs), use the column in the above table with the planned number of KSs in the expanded network so that the new KS or KSs can be added later.
Following are additional guidelines for assigning KSSIDs to KSs:
Configure only contiguous blocks of KSSIDs across KSs (for example, KS1 = 0-9 + 40-49, KS2 = 10-19 + 50-59, KS3 = 20-29, KS4 = 30-39, and so on).
Any one KS should have enough KSSID space to receive all GM registrations from the group (in case the other KSs fail all of their GM registrations).
To avoid reinitialization of the group, only add new KSSID values or ranges; do not remove them unless necessary.
During a network split (a connectivity loss among cooperative KSs), do not change the KSSID assignment; this prevents overlapping KSSIDs, which would cause reinitialization on a merge (when connectivity has been restored among cooperative KSs).
If the group begins in an n-way split (meaning that secondary KSs are planned but not yet configured), configure all of the KSSIDs as if the group was not split.
The number of KSSIDs available depends on the group size configuration as in the following table:
Configured Group Size |
Number of Available KSSIDs |
---|---|
Small (8-bit) |
0 to 1 |
Small (12-bit) |
0 to 3 |
Small (16-bit) |
0 to 15 |
Medium |
0 to 127 |
Large |
0 to 511 |
Group reinitialization is the process of retiring KSSIDs. Group reinitialization occurs across all KSs (primary and secondary). Any KS can trigger a group reinitialization, and it occurs whenever
You change the TEK policy from non-GCM to GCM.
You change the group size.
You remove a previously used KSSID.
A KS in the group runs out of both KSSIDs and GMSIDs.
A KSSID overlap that was detected by a cooperative KS is resolved.
During reinitialization, all KSs move their used KSSIDs to old (used) KSSIDs (and they are thus retired). Then, reinitialization creates a new KEK and new TEKs, lowers the existing TEK lifetime, and deletes the existing TEKs to cause all GMs to re-register (within the window determined by the clear crypto gdoi ks members command). This window is five percent of the remaining lifetime, between 90 seconds and one hour. When the lifetime of the existing TEKs has expired, each KS resets its old (used) KSSIDs, then all KSSIDs are available for use once again.
Reinitialization does not cause traffic disruption on the GMs. All GMs receive new GMSIDs with new TEKs when re-registering.
The tables below explain the GET VPN system logging (also called syslog) messages that are related to Suite B.
Message |
Explanation |
---|---|
%GDOI-5-GM_IV_EXHAUSTED: GM for group group-name exhausted its IV space for interface interface-name and will re-register. |
The GM for the group exhausted its IV space (meaning its set of unique IVs) for a particular SA and will re-register. |
%GDOI-5-GM_REJECTING_SA_PAYLOAD: Registration: Policy in SA payload sent by KS ip-address rejected by GM in the group group-name reason: client rekey hash algorithm (kek-policy) is unacceptable by this GM. |
The client rekey hash algorithm (the specified KEK policy) was not accepted by a GM in the specified group. At registration, the GM rejected the KEK policy. |
%GDOI-5-GM_REJECTING_SA_PAYLOAD: Registration: Policy in SA payload sent by KS ip-address rejected by GM in the group group-name reason : client rekey transform-sets (tek-policy) for data-protection are unacceptable by this GM. |
The client rekey transform sets (the specified TEK policy) for data protection was not accepted by the GM. At registration, the GM rejected the TEK policy. |
%GDOI-5-GM_REKEY_TRANSFORMSET_CHECK_FAIL: The transform set (transform-set) for data protection in group group-name is unacceptable by this client. |
The transform set for data protection in the group was not accepted by the client. The GM received a rekey and rejected the TEK policy. |
%GDOI-3-KS_REKEY_AUTH_KEY_LENGTH_INSUFFICIENT: Rejected rekey sig-hash algorithm change: using sig-hash algorithm HMAC_AUTH_SHAbits requires an authentication key length of at least number-of-bits bits (number-of-blocks blocks in bytes) - current RSA key "360-bit" is only 45 blocks in bytes. |
Configuration of the rekey signature hash algorithm was rejected, because the RSA key did not have a long enough modulus. HMAC-SHA-384 requires a modulus of at least 465 bits (59 blocks in bytes), and HMAC-SHA-512 requires a modulus of 593 bits (75 blocks in bytes). |
Each feature in the GET VPN Support with Suite B feature set is independently configurable. But to be compliant with the Suite B standard, you must configure certain combinations of these features. For more information about these combinations, see RFC 4869, Suite B Cryptographic Suites for IPsec.
Because GET VPN is a technology that is based on groups, all devices in the same group (including the primary KS, cooperative KSs, and GMs) must support the Suite B feature before you can enable the feature. If you want to enable the feature for a group, you must ensure that all devices in the group are running compatible versions of the GET VPN software.
To ensure that all devices in the GET VPN network support Suite B, perform the following steps on the KS (or primary KS).
1.
enable
2.
show
crypto
gdoi
feature
suite-b
3.
show
crypto
gdoi
feature
suite-b
|
include
No
Perform this task to configure the signature hash algorithm for the KEK.
This task has the following prerequisites:
Make sure that rekey authentication that is using an RSA key pair associated with the device is enabled. To do so, use the rekey authentication command with the mypubkey rsa key-name keywords and argument.
Make sure that the RSA key pair has a modulus of sufficient length. HMAC-SHA-384 requires a modulus of at least 465 bits (59 blocks in bytes), and HMAC-SHA-512 requires a modulus of 593 bits (75 blocks in bytes). If the rekey signature hash algorithm is changed to SHA-384 or SHA-512 with a key pair of insufficient modulus length, a configuration rejection message appears on the console, and system logging messages are generated. Similarly, if the rekey signature hash algorithm is already SHA-384 or SHA-512 and the key pair is modified to one of insufficient modulus length, a similar message appears on the console, and the same system logging messages are generated.
To use SHA-2/HMAC-SHA-2 for authentication of the acknowledgment from GMs to KSs after receiving a rekey message, you must enable unicast distribution of rekey messages to GMs. To do so, use the rekey transport unicast command.
1.
enable
2.
configure
terminal
3.
crypto
gdoi
group [ipv6]
group-name
4.
server
local
5.
rekey sig-hash algorithm
algorithm
6.
end
This task is optional. For nearly all deployments, the default group size (sender identifier length) of medium is recommended. Perform this task to configure the group size for Suite B.
When you change the group size in a group with cooperative KSs after Suite B (meaning ESP-GCM or ESP-GMAC) is configured and after the Suite B policy has been generated, you must change the group size on all secondary KSs before changing it on the primary KS.
Changing the group size causes the group to reinitialize (so that the new SID length can be used). Conflicting group size configurations across KSs will block GM registration.
1.
enable
2.
configure
terminal
3.
crypto
gdoi
group [ipv6]
group-name
4.
server
local
5.
group
size {small {8 |
12 |
16} |
medium |
large}
6.
end
Suite B requires the assignment of unique GMSIDs to each GM, which means that a GM cannot reuse a previously used SID (either from itself or another GM) for the same key. Therefore, although GET VPN is designed to disallow overlapping SID values, you should correctly configure KSSID values among KSs so that each KS has a unique set. (KSSID overlap among KSs will cause a reinitialization.)
You must configure at least one unique KSSID to allot a pool of SIDs to the KS. You do so on the KS before configuring GCM or GMAC as the TEK IPsec policy.
Perform this task to assign a KSSID or a range of KSSIDs to a KS. Each KS must be assigned at least one KSSID when using GCM or GMAC. You can configure a single KSSID, a range of KSSIDs, or both. For the default group size of medium, there are 128 possible KSSID values in the range from 0 to 127.
KSSID values are not assigned to (and usable by) the KS until you exit GDOI local server ID configuration mode.
1.
enable
2.
configure
terminal
3.
crypto
gdoi
group [ipv6]
group-name
4.
server
local
5.
identifier
6.
range
lowest-kssid
-
highest-kssid
7.
value
kssid
8.
end
If you try to configure one or more KSSIDs on a KS that are already assigned to another KS (and the cooperative KS network is not split), the configuration is denied, and the following message appears when you exit GDOI local server ID configuration mode:
% Key Server SID Configuration Denied: % The following Key Server SIDs being added overlap: % 2, 200-250 (COOP-KS Peer: 10.0.9.1)
If the cooperative KS network is split, you should not configure overlapping KSSIDs. If overlapping KSSIDs are detected on a network merge, GM registration is blocked until the overlap is resolved. The following system logging message appears on both KSs:
%GDOI-3-COOP_KSSID_OVERLAP: Overlapping KS Sender Identifier(s) (KSSID) {2, 200-250} with COOP-KS peer 10.0.9.1 in group diffint blocking GM registration (MISCONFIG)
When a KS unconfigures the overlapping KSSIDs, the group reinitializes (meaning that all GMs are forced to re-register, and TEK IPsec SAs are rekeyed to reset the used KSSIDs) without traffic loss. The following system logging messages appear on the KS:
%SYS-5-CONFIG_I: Configured from console by console %GDOI-5-COOP_KSSID_OVERLAP_RESOLVED: Resolved overlapping KS Sender Identifier(s) (KSSID) with COOP-KS peer allowing GM registrations once again %GDOI-5-KS_REINIT_GROUP: KSSID overlap was resolved for group diffint and will re-initialize the group. %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group diffint from address 10.0.8.1 with seq # 11 %GDOI-4-GM_DELETE: GM 10.0.3.1 deleted from group diffint. %GDOI-4-GM_DELETE: GM 10.65.9.2 deleted from group diffint.
The %GDOI-5-KS_SEND_UNICAST_REKEY system logging message appears only if this is the primary KS. The peer KS that had overlapping KSSIDs also displays the %GDOI-5-COOP_KSSID_OVERLAP_RESOLVED system logging message.
To configure the IPsec SA for Suite B, perform the following steps.
1.
enable
2.
configure
terminal
3.
crypto
ipsec
transform-set
transform-set-name
{esp-gcm |
esp-gmac} [128 |
192 |
256]
4.
crypto
ipsec
profile
ipsec-profile-name
5.
set
transform-set
transform-set-name
6.
exit
7.
crypto
gdoi
group [ipv6]
group-name
8.
Enter one of the following commands:
9.
server
local
10.
sa
ipsec
sequence-number
11.
profile
ipsec-profile-name
12.
match
address
{ipv4 |
ipv6} {access-list-number |
access-list-name}
13.
end
To configure the Suite B ciphers and hash algorithms for KEK to be allowed by the GM, perform the following steps.
1.
enable
2.
configure
terminal
3.
crypto
gdoi
group [ipv6]
group-name
4.
Enter one of the following commands:
5.
server
address
ipv4
address
6.
client
rekey
encryption
cipher
[... [cipher]]
7.
client
rekey
hash
hash
8.
end
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example: Device> enable |
Enables privileged EXEC mode. |
Step 2 |
configure
terminal
Example: Device# configure terminal |
Enters global configuration mode. |
Step 3 |
crypto
gdoi
group [ipv6]
group-name
Example: Device(config)# crypto gdoi group gdoigroupone |
Identifies a GDOI group and enters GDOI group configuration mode. |
Step 4 | Enter one of the following commands:
Example: Device(config-gdoi-group)# identity number 3333 Example: Device(config-gdoi-group)# identity address ipv4 10.2.2.2 |
Identifies a GDOI group number or address. |
Step 5 |
server
address
ipv4
address
Example: Device(config-gdoi-group)# server address ipv4 10.0.5.2 |
Specifies the address of the server that a GDOI group is trying to reach. |
Step 6 |
client
rekey
encryption
cipher
[... [cipher]]
Example: Device(config-gdoi-group)# client rekey encryption 3des-cbc aes 192 aes 256 |
Sets the client acceptable rekey ciphers for the KEK. |
Step 7 |
client
rekey
hash
hash
Example: Device(config-gdoi-group)# client rekey hash sha384 |
Sets the client acceptable hash algorithm for KEK. |
Step 8 |
end
Example: Device(config-gdoi-group)# end |
Exits GDOI group configuration mode and returns to privileged EXEC mode. |
To configure the transform sets used by TEKs for data encryption or authentication to be allowed by the GM, perform the following steps.
1.
enable
2.
configure
terminal
3.
crypto
ipsec
transform-set
transform-set-name
{esp-gcm |
esp-gmac} [128 |
192 |
256]
4.
exit
5.
crypto
gdoi
group [ipv6]
group-name
6.
client
transform-sets
transform-set-name1
[... [transform-set-name6]]
7.
end
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
Example: Device> enable |
Enables privileged EXEC mode. |
Step 2 |
configure
terminal
Example: Device# configure terminal |
Enters global configuration mode. |
Step 3 |
crypto
ipsec
transform-set
transform-set-name
{esp-gcm |
esp-gmac} [128 |
192 |
256]
Example: Device(config)# crypto ipsec transform-set g1 esp-gcm 192 |
Defines a transform set—an acceptable combination of security protocols and algorithms—and enters crypto transform configuration mode. |
Step 4 |
exit
Example: Device(cfg-crypto-trans)# exit |
Exits crypto transform configuration mode. |
Step 5 |
crypto
gdoi
group [ipv6]
group-name
Example: Device(config)# crypto gdoi group gdoigroupone |
Identifies a GDOI group and enters GDOI group configuration mode. |
Step 6 |
client
transform-sets
transform-set-name1
[... [transform-set-name6]]
Example: Device(config-gdoi-group)# client transform-sets g1 |
Specifies the acceptable transform-set tags used by TEKs for data encryption and authentication. |
Step 7 |
end
Example: Device(config-gdoi-group)# end |
Exits GDOI group configuration mode and returns to privileged EXEC mode. |
Verifying and Troubleshooting GET VPN Support with Suite B
To view the configuration that is running on a KS, use the show running-config command.
1.
show crypto gdoi ks identifier [detail]
2.
show crypto gdoi ks coop identifier [detail]
3.
show crypto gdoi feature suite-b
4.
show crypto gdoi ks policy
Step 1 |
show crypto gdoi ks identifier [detail]
Example: Device# show crypto gdoi ks identifier detail KS Sender ID (KSSID) Information for Group diffint: Transform Mode : Counter (Suite B) reinitializing : No SID Length (Group Size) : 24 bits (medium) Current KSSID In-Use : 0 Last GMSID Used : 1 KSSID (or SIDS)Assigned : 0-15 KSSID (or SIDS)Used : 0 KSSID (or SIDS) Used (Old) : none Available KSSID (or SIDS): 1-15 REMAINING SIDs: KSSID to reinitialize at : 15 GMSID to reinitialize at : 6291456 # of SIDs Remaining for Cur KSSID : 8388606 # of SIDs Remaining until Re-init : 132120575 This command displays the status of SID management for Suite B. The Transform Mode field can be either Non-Counter (Non-Suite B) or Counter (Suite B) to check if SID management and a Suite B policy is currently used in the group. If the group is currently reinitializing (meaning that all GMs will be forced to re-register, and TEK IPsec SAs will be rekeyed to reset the used KSSIDs), then the reinitializing field displays Yes. The SID Length (Group Size) field determines the group size currently used in the group, which defaults to 24 bits (medium). The Current KSSID In-Use and Last GMSID Used fields correspond to the SID (or SIDS) to be distributed to the next registering GM. The KSSID (or SIDS) Assigned field corresponds to the locally configured KSSIDs that have been synced with cooperative KSs, and the Available KSSID (or SIDS) field corresponds to those KSSIDs that have not been used yet since the last reinitialization. Each time a new KSSID is used, it is added to the KSSID (or SIDS) Used field, and during a reinitialization, those used KSSIDs are transferred to the KSSID (or SIDS) Used (Old) field. At the end of a reinitialization period, the old used KSSIDs are cleared and put in the Available KSSIDs pool again.
| ||
Step 2 |
show crypto gdoi ks coop identifier [detail]
Example: Device# show crypto gdoi ks coop identifier detail COOP-KS Sender ID (SID) Information for Group diffint: Local KS Role: Primary , Local KS Status: Alive Local Address : 10.0.8.1 Next SID Client Operation : NOTIFY reinitializing : No KSSID Overlap : No SID Length (Group Size) Cfg : 24 bits (medium) SID Length (Group Size) Used : 24 bits (medium) Current KSSID In-Use : 0 KSSID (or SIDS)Assigned : 0-15 KSSID (or SIDS)Used : 0 Old KSSID (or SIDS)Used : none Peer KS Role: Secondary , Peer KS Status: Alive Peer Address : 10.0.9.1 Next SID Client Operation : NOTIFY reinitializing : No KSSID Overlap : No SID Length (Group Size) Cfg : 24 bits (medium) SID Length (Group Size) Used : 24 bits (medium) Current KSSID In-Use : 16 KSSID (or SIDS)Assigned : 16-31 KSSID (or SIDS)Used : 16 Old KSSID (or SIDS)Used : none This command displays the status of SID information that is synchronized across cooperative KSs. When the KSSID Overlap field displays Yes, GM registration is blocked until the overlap of KSSIDs (which could have happened during a network split) is resolved. You must unconfigure the overlapping KSSIDs from one cooperative KS or the other before GM registration can resume. When the overlapping KSSIDs are resolved, a reinitialization occurs. When you change the group size (not recommended for most deployments), all secondary KSs must first configure the new group size. Then on the primary KS, the SID Length (Group Size) Cfg field displays the new group size on all cooperative KS peers. Only when the primary KS configures the new group size will all KSs start to use the new group size and update the SID Length (Group Size) Used field to display the new group size. | ||
Step 3 |
show crypto gdoi feature suite-b
Example: Device# show crypto gdoi feature suite-b Group Name: diffint Key Server ID Version Feature Supported 10.0.8.1 1.0.4 Yes 10.0.9.1 1.0.4 Yes Group Member ID Version Feature Supported 10.0.3.1 1.0.4 Yes 10.0.4.1 1.0.4 Yes This command displays whether KSs and GMs can use the Suite B feature set (meaning AES-GCM, AES-GMAC, SHA-2, and HMAC-SHA2). The Version field must display 1.0.4 or higher, and the Feature Supported field must display Yes for all KSs in the cooperative KS group and for the registered GMs. | ||
Step 4 |
show crypto gdoi ks policy
Example: Device# show crypto gdoi ks policy Key Server Policy: For group diffint (handle: 2147483650) server 10.0.8.1 (handle: 2147483650): # of teks : 4 Seq num : 0 KEK POLICY (transport type : Unicast) spi : 0x80474E999FE8F60364B7F51809E28C84 management alg : disabled encrypt alg : 3DES crypto iv length : 8 key size : 24 orig life(sec): 86400 remaining life(sec): 85586 sig hash algorithm : enabled sig key length : 162 sig size : 128 sig key name : mykeys TEK POLICY (encaps : ENCAPS_TUNNEL) spi : 0x9C666FA7 access-list : gcm-acl Selector : permit ip host 10.0.1.1 host 239.0.1.1 transform : esp-gcm alg key size : 20 sig key size : 0 orig life(sec) : 900 remaining life(sec) : 87 tek life(sec) : 900 elapsed time(sec) : 813 override life (sec): 0 antireplay window size: 64 TEK POLICY (encaps : ENCAPS_TUNNEL) spi : 0x54E8D5D3 access-list : gcm-acl Selector : permit ip host 10.0.100.2 host 238.0.1.1 transform : esp-gcm alg key size : 20 sig key size : 0 orig life(sec) : 900 remaining life(sec) : 87 tek life(sec) : 900 elapsed time(sec) : 813 override life (sec): 0 antireplay window size: 64 TEK POLICY (encaps : ENCAPS_TUNNEL) spi : 0xC8B4DE6D access-list : gcm-acl Selector : permit ip host 10.0.1.1 host 10.0.100.2 transform : esp-gcm alg key size : 20 sig key size : 0 orig life(sec) : 900 remaining life(sec) : 87 tek life(sec) : 900 elapsed time(sec) : 813 override life (sec): 0 antireplay window size: 64 TEK POLICY (encaps : ENCAPS_TUNNEL) spi : 0x1C908AF3 access-list : gcm-acl Selector : permit ip host 10.0.100.2 host 10.0.1.1 transform : esp-gcm alg key size : 20 sig key size : 0 orig life(sec) : 900 remaining life(sec) : 87 tek life(sec) : 900 elapsed time(sec) : 813 This command displays whether a TEK and IPsec SA were generated per ACE (displayed in the Selector field) from the ACL in the access-list field for the ESP-GCM or ESP-GMAC TEK policy. This command also displays whether the KEK policy is using SHA-2/HMAC-SHA-2 as the signature hash algorithm. |
To view the configuration that is running on a GM, use the show running-config command.
1.
show crypto gdoi gm identifier [detail]
2.
show crypto gdoi feature suite-b
3.
show crypto gdoi
Step 1 |
show crypto gdoi gm identifier [detail]
Example: Device# show crypto gdoi gm identifier detail GM Sender ID (SID) Information for Group diffint: Group Member: 10.65.9.2 vrf: None Transform Mode : Counter (Suite B) # of SIDs Last Requested : 3 CURRENT SIDs: Shared Across Interfaces? : Yes SID Length (Group Size) : 24 bits (medium) # of SIDs Downloaded : 3 First SID Downloaded : 0x08000007 Last SID Downloaded : 0x08000009 CM Interface B/W (Kbps) MTU (B) # Req # Rx Installed SID Range ============== ========== ======== ===== ===== ======================= Et2/0 10000 1500 1 3 0x08000007 - 0x08000009 Et3/0 10000 1500 1 3 0x08000007 - 0x08000009 Et4/0 10000 1500 1 3 0x08000007 - 0x08000009 NEXT SID REQUEST: TEK Lifetime : 900 sec SID Length (Group Size) : 32 bits (LARGE) This command displays the status of received and installed SIDs on a GM when it is using GCM-AES or GMAC-AES as the TEK IPsec SA policy. The Transform Mode field can display Non-Counter (Non-Suite B) or Counter (Suite B) to check whether SIDs are being downloaded and installed and whether a Suite B policy is used in the group. The # of SIDs Last Requested field mainly depends on the number of interfaces to which the crypto map is applied for this registered GM (meaning using the local-address or client registration interface). The SIDs are Shared Across Interfaces field when using local-address and each CM Interface’s Installed SID Range field will be the same. You use this command mainly to verify that each CM interface has SIDs installed. |
Step 2 |
show crypto gdoi feature suite-b
Example: Device# show crypto gdoi feature Suite B Version Feature Supported 1.0.4 Yes This command displays whether this GM can use the Suite B feature set (meaning GCM-AES, GMAC-AES, SHA-2, and HMAC-SHA-2). The Version field must display 1.0.4 or higher, and the Feature Supported field must display Yes. |
Step 3 |
show crypto gdoi
Example: Device# show crypto gdoi GROUP INFORMATION Group Name : diffint Group Identity : 1234 Crypto Path : ipv4 Key Management Path : ipv4 Rekeys received : 0 IPSec SA Direction : Both Group Server list : 10.0.8.1 Group member : 10.0.3.1 vrf: None Version : 1.0.4 Registration status : Registered Registered with : 10.0.8.1 . . . ACL Downloaded From KS 10.0.8.1: access-list permit ip host 10.0.1.1 host 239.0.1.1 access-list permit ip host 10.0.100.2 host 238.0.1.1 access-list permit ip host 10.0.1.1 host 10.0.100.2 access-list permit ip host 10.0.100.2 host 10.0.1.1 KEK POLICY: Rekey Transport Type : Unicast Lifetime (secs) : 85740 Encrypt Algorithm : 3DES Key Size : 192 Sig Hash Algorithm : HMAC_AUTH_SHA256 Sig Key Length (bits) : 1024 TEK POLICY for the current KS-Policy ACEs Downloaded: Ethernet3/0: IPsec SA: spi: 0x318846DE(831014622) transform: esp-gcm sa timing:remaining key lifetime (sec): (86350) Anti-Replay(Counter Based) : 64 IPsec SA: spi: 0xF367AEA0(4083658400) transform: esp-gcm sa timing:remaining key lifetime (sec): (86350) Anti-Replay(Counter Based) : 64 IPsec SA: spi: 0xE583A3F5(3850609653) transform: esp-gcm sa timing:remaining key lifetime (sec): (86350) Anti-Replay(Counter Based) : 64 IPsec SA: spi: 0xE9AC04C(245022796) transform: esp-gcm sa timing:remaining key lifetime (sec): (86350) Anti-Replay(Counter Based) : 64 The presence of multiple IPsec SAs shows that GCM or GMAC is configured (note that each IPsec SA has a unique SPI for each ACE that was downloaded). For each ACE listed in the TEK POLICY for the current KS-Policy ACEs Downloaded section, this command displays whether a TEK policy and IPsec SA were downloaded (and installed) from the ACLs that are listed in the ACL Downloaded From KS section. This command also displays whether the KEK policy is using SHA-2/HMAC-SHA-2 for the signature hash algorithm (for example, HMAC_AUTH_SHA256). |
Configuration Examples for GET VPN Support with Suite B
The following example shows how to use the GET VPN software versioning command on the KS (or primary KS) to check whether all the devices in each group support Suite B cryptography:
Device# show crypto gdoi feature suite-b Group Name: GETVPN Key Server ID Version Feature Supported 10.0.5.2 1.0.4 Yes 10.0.6.2 1.0.4 Yes 10.0.7.2 1.0.3 No 10.0.8.2 1.0.2 No Group Member ID Version Feature Supported 10.0.1.2 1.0.2 No 10.0.2.5 1.0.3 No 10.0.3.1 1.0.4 Yes 10.0.3.2 1.0.4 Yes
You can also enter the above command on a GM (which will display the information for the GM but not for the KS or other GMs).
The following example shows how to enter the command on the KS (or primary KS) find only those devices in the GET VPN network that do not support Suite B:
Device# show crypto gdoi feature suite-b | include No 10.0.7.2 1.0.3 No 10.0.8.2 1.0.2 No 10.0.1.2 1.0.2 No 10.0.2.5 1.0.3 No
The following example shows how to configure the signature hash algorithm for the KEK:
Device> enable Device# configure terminal Device(config)# crypto gdoi group mygroup Device(config-gdoi-group)# server local Device(gdoi-local-server)# rekey sig-hash algorithm sha512 Device(gdoi-local-server)# end
Configuring the group size for Suite B is optional, because the default group size of medium is sufficient for most deployments. The following example shows how to configure the group size for Suite B:
Device> enable Device# configure terminal Device(config)# crypto gdoi group mygroup Device(config-gdoi-group)# server local Device(gdoi-local-server)# group size small 16 Device(gdoi-local-server)# end
The following example shows how to assign a KSSID as well as a range of KSSIDs to a KS:
Device> enable Device# configure terminal Device(config)# crypto gdoi group mygroup Device(config-gdoi-group)# server local Device(gdoi-local-server)# identifier Device(gdoi-local-server-id)# range 10 - 20 Device(gdoi-local-server-id)# value 0 Device(gdoi-local-server-id)# end
The following example shows how to configure the IPsec SA for Suite B. This example uses an identity number instead of an identity address:
Device> enable Device# configure terminal Device(config)# crypto ipsec transform-set g1 esp-gcm 192 Device(config)# crypto ipsec profile profile1 Device(ipsec-profile)# set transform-set transformset1 Device(ipsec-profile)# exit Device(config)# crypto gdoi group gdoigroupname Device(config-gdoi-group)# identity number 3333 Device(config-gdoi-group)# server local Device(gdoi-local-server)# sa ipsec 1 Device(gdoi-sa-ipsec)# profile gdoi-p Device(gdoi-sa-ipsec)# match address ipv4 102 Device(gdoi-sa-ipsec)# end
The following example shows how to configure the Suite B ciphers and hash algorithms for the KEK to be allowed by the GM. This example uses an identity address (compatible only with IPv4 data plane configurations). You could instead use an identity number (which would be compatible with IPv4 and IPv6 data plane configurations).
Device> enable Device# configure terminal Device(config)# crypto gdoi group gdoigroupone Device(config-gdoi-group)# identity address ipv4 10.2.2.2 Device(config-gdoi-group)# server address ipv4 10.0.5.2 Device(config-gdoi-group)# client rekey encryption 3des-cbc aes 192 aes 256 Device(config-gdoi-group)# client rekey hash sha384 Device(config-gdoi-group)# end
The following example shows how to configure the acceptable transform sets used by TEKs for data encryption or authentication.
Device> enable Device# configure terminal Device(config)# crypto ipsec transform-set g1 esp-gcm 192 Device(cfg-crypto-trans)# exit Device(config)# crypto gdoi group gdoigroupone Device(config-gdoi-group)# client transform-sets g1 Device(config-gdoi-group)# end
Related Topic |
Document Title |
---|---|
Cisco IOS commands |
|
Cisco IOS security commands |
Cisco IOS Security Command References |
IKE and IKE policy configuration tasks IPsec transform configuration tasks |
“Configuring Internet Key Exchange for IPsec VPNs” module in the Internet Key Exchange for IPsec VPNs Configuration Guide, Cisco IOS Release 15.2M&T |
Basic deployment guidelines for enabling GET VPN in an enterprise network |
Standard/RFC |
Title |
---|---|
Federal Information Processing Standard (FIPS) Publication 140-2 |
|
RFC 2401 |
|
RFC 4106 |
The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) |
RFC 4543 |
The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH |
RFC 4869 |
|
RFC 6054 |
|
RFC 6407 |
Description |
Link |
---|---|
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. |
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.Feature Name |
Releases |
Feature Information |
---|---|---|
GET VPN Support with Suite B |
Cisco IOS XE Release 3.10S |
The GET VPN Support with Suite B feature adds support of the Suite B set of ciphers to Cisco Group Encrypted Transport (GET) VPN. Suite B is a set of cryptographic algorithms that includes Galois Counter Mode Advanced Encryption Standard (GCM-AES) as well as algorithms for hashing, digital signatures, and key exchange. Suite B for IP security (IPsec) VPNs is a standard whose usage is defined in RFC 4869. Suite B provides a comprehensive security enhancement for Cisco IPsec VPNs, and it allows additional security for large-scale deployments. Suite B is the recommended solution for organizations requiring advanced encryption security for the wide-area network (WAN) between remote sites. The following commands were introduced or modified: client rekey hash, crypto key export ec, crypto key generate ec keysize, crypto key import ec, group size, identifier, rekey sig-hash algorithm, show crypto gdoi. |