Network Security
Define IKE Crypto Profiles
Table of Contents
Define IKE Crypto Profiles
The IKE Crypto profile is used to set up encryption and authentication algorithms for
the key exchange process in IKE Phase 1. It must be configured identically on all IKE
gateways.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
|
The Internet Key Exchange (IKE) profiles provide information about the algorithms
that are used to authenticate, encrypt, and establish a shared secret between
network sites when you establish an IPSec tunnel.
The IKE Crypto profile is used to set up the encryption and authentication algorithms
used for the key exchange process in IKE Phase 1, and lifetime
of the keys, which specifies how long the keys are valid. To invoke the profile, you
must attach it to the IKE Gateway configuration.
All IKE gateways configured on the same interface or local IP address must use
the same crypto profile when the IKE gateway’s Peer IP Address
Type is configured as Dynamic and IKEv1
main mode or IKEv2 is applied. If the crypto profiles are the same on the
gateways, although the initial connection might start off on a different
gateway, the connection will shift to the proper gateway when pre-shared keys or
certificates and peer IDs are exchanged.
Regardless of whether your VPN peer is from the same vendor or not, the VPN peers
must have the same IKE parameters configured in order to perform a successful IKE
negotiation.
The following parameters need to match for a successful IKE negotiation:
- DH Group for key exchange
- Encryption algorithms
- Authentication algorithms
For example, if you have configured VPN peer 1 with group20
for DH group, sha384 for authentication, and
aes-256-gcm for encryption. Then, VPN peer 2 with which
you want to establish the IPSec tunnel also should have the same values
configured.
Follow this procedure to create an IKE Crypto profile on a Palo Alto Networks
firewall.
Define IKE Crypto Profiles (PAN-OS 10.1 and Later & )
- Create a new IKE profile.
- Select and select Add.Enter a Name for the new profile.Specify the Diffie-Hellman (DH) Group for key exchange and the Authentication and Encryption algorithms.Click Add in the corresponding sections (DH Group, Authentication, and Encryption) and select from the menus.If you aren’t certain what the VPN peers support, add multiple groups or algorithms in the order of most-to-least secure; the peers negotiate the strongest supported group or algorithm to establish the tunnel.
- DH Group—
- (PAN-OS 10.2.0 and later releases) group21 (on IKEv2 only mode)
- group20
- (PAN-OS 10.2.0 and later releases) group16 (on IKEv2 only mode)
- (PAN-OS 10.2.0 and later releases) group15 (on IKEv2 only mode)
- group19
- group14
- group5
- group2
- group1
- Authentication—
- sha512
- sha384
- sha256
- sha1
- md5
- (PAN-OS 10.0.3 and later releases) non-auth
If you select an AES-GCM algorithm for encryption, you must select the Authentication setting non-auth or the commit will fail. The hash is automatically selected based on the DH Group selected. DH Group 19 and below uses sha256; DH Group 20 uses sha384. - Encryption—
- (PAN-OS 10.0.3 and later releases) aes-256-gcm (requires IKEv2; DH Group should be set to group20)
- (PAN-OS 10.0.3 and later releases) aes-128-gcm (requires IKEv2 and DH Group set to group19)
- aes-256-cbc
- aes-192-cbc
- aes-128-cbc
- 3des
- (PAN-OS 10.1.0 and earlier releases) des
Choose the strongest authentication and encryption algorithms that the peer can support. For the authentication algorithm, use SHA-256 or higher (SHA-384 or higher preferred for long-lived transactions). Don’t use SHA-1 or MD5. For the encryption algorithm, use AES; DES and 3DES are weak and vulnerable. AES with Galois/Counter Mode (AES-GCM) provides the strongest security and has built-in authentication, so you must set Authentication to non-auth if you select aes-256-gcm or aes-128-gcm encryption.Specify the duration for which the key is valid and the reauthentication interval.For details, see SA Key Lifetime and Re-Authentication Interval.- In the Key Lifetime fields, specify the period (in seconds, minutes, hours, or days) for which the key is valid (range is 3 minutes to 365 days; default is 8 hours). When the key expires, the firewall renegotiates a new key. A lifetime is the period between each renegotiation.For the IKEv2 Authentication Multiple, specify a value (range is 0-50; default is 0) that is multiplied by the Key Lifetime to determine the authentication count. The default value of zero disables the reauthentication feature.Commit your IKE Crypto profile.Click OK and click Commit.Attach the IKE Crypto profile to the IKE Gateway configuration.
Define IKE Crypto Profiles (Strata Cloud Manager)
Based on the IPSec device type you selected, Prisma Access provides a recommended set of ciphers and a key lifetime for the IKE Phase 1 key exchange process between:- the private apps at your data center or headquarters location and Prisma Access—for a service connection
- the remote network site device and Prisma Access—for a remote network site
You can use the recommended settings, or customize the settings as needed for your environment.- Select an IKE Protocol Version for your IPSec device and Prisma Access to use for IKE negotiation.If you select IKEv1 Only Mode, Prisma Access can use only the IKEv1 protocol for the negotiation. If you select IKEv2 Only Mode, Prisma Access can use only the IKEv2 protocol for the negotiation.If you select IKEv2 Preferred Mode, Prisma Access uses the IKEv2 protocol only if your IPSec device(for service connection)/branch IPSec device(for remote network site) also supports IKEv2. If your IPSec device does not support IKEv2, Prisma Access falls back to using the IKEv1 protocol.Add an IKEv1 Crypto Profile to customize the IKE crypto settings that define the encryption and authentication algorithms used for the key exchange process in IKE Phase 1.Prisma Access automatically uses a default IKE crypto profile based on the Branch Device Type that’s being used to establish this tunnel.
- Encryption—Specify the encryption algorithm used in the IKE SA negotiation.Prisma Access supports the following encryption algorithms: 3des (168 bits), aes-128-cbc (128 bits), aes-192-cbc (192 bits), aes-256-cbc (256 bits), and des (56 bits). You can also select null (no encryption).
- Authentication—Specify the authentication algorithm used in the IKE SA negotiation.Prisma Access supports the following authentication algorithms: sha1 (160 bits), sha256 (256 bits), sha384 (384 bits), sha512 (512 bits), and md5 (128 bits). You can also select null (no authentication).
- DH Group—Specify the Diffie-Hellman (DH) groups used to generate symmetrical keys for IKE in the IKE SA negotiation. The Diffie-Hellman algorithm uses the private key of one party and the public key of the other to create a shared secret, which is an encrypted key that both VPN tunnel peers share.Prisma Access supports the following DH groups: Group 1 (768 bits), Group 2 (1024 bits—default), Group 5 (1536 bits), Group 14 (2048 bits), Group 19 (256-bit elliptic curve group), and Group 20 (384-bit elliptic curve group). For the strongest security, select the group with the highest number.
- Lifetime—Specify the unit and amount of time for which the IKE Phase 1 key is valid (default is 8 hours). For IKEv1, the security association (SA) is not actively re-keyed before the key lifetime expires. The IKEv1 Phase 1 re-key triggers only when the SA expires. For IKEv2, the SA must be re-keyed before the key lifetime expires. If the SA is not re-keyed upon expiration, the SA must begin a new Phase 1 key.
- IKEv2 Authentication Multiple—Specify the value that is multiplied by the key lifetime to determine the authentication count (range is 0 to 50; default is 0). The authentication count is the number of times that the security processing node can perform IKEv2 IKE SA re-key before it must start over with IKEv2 re-authentication. The default value of 0 disables the re-authentication feature.
Enable IKE Passive Mode so that Prisma Access only response to IKE connections and does not initiate them.IKE NAT Traversal is turned on by default.This means that UDP encapsulation is used on IKE and UDP protocols, enabling them to pass through network address translation (NAT) devices that are between the IPSec VPN tunnel endpoints.
