Network Security
IKE Phase 2
Table of Contents
Expand All
|
Collapse All
Network Security Docs
-
- Security Policy
-
- Security Profile Groups
- Security Profile: AI Security
- Security Profile: WildFire® Analysis
- Security Profile: Antivirus
- Security Profile: Vulnerability Protection
- Security Profile: Anti-Spyware
- Security Profile: DNS Security
- Security Profile: DoS Protection Profile
- Security Profile: File Blocking
- Security Profile: URL Filtering
- Security Profile: Data Filtering
- Security Profile: Zone Protection
-
- Policy Object: Address Groups
- Policy Object: Regions
- Policy Object: Traffic Objects
- Policy Object: Applications
- Policy Object: Application Groups
- Policy Object: Application Filter
- Policy Object: Services
- Policy Object: Auto-Tag Actions
- Policy Object: Devices
-
- Uses for External Dynamic Lists in Policy
- Formatting Guidelines for an External Dynamic List
- Built-in External Dynamic Lists
- Configure Your Environment to Access an External Dynamic List
- Configure your Environment to Access an External Dynamic List from the EDL Hosting Service
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Policy Object: HIP Objects
- Policy Object: Schedules
- Policy Object: Quarantine Device Lists
- Policy Object: Dynamic User Groups
- Policy Object: Custom Objects
- Policy Object: Log Forwarding
- Policy Object: Authentication
- Policy Object: Decryption Profile
- Policy Object: Packet Broker Profile
-
-
-
- The Quantum Computing Threat
- How RFC 8784 Resists Quantum Computing Threats
- How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
- Support for Post-Quantum Features
- Post-Quantum Migration Planning and Preparation
- Best Practices for Resisting Post-Quantum Attacks
- Learn More About Post-Quantum Security
-
-
-
- Investigate Reasons for Decryption Failure
- Identify Weak Protocols and Cipher Suites
- Troubleshoot Version Errors
- Troubleshoot Unsupported Cipher Suites
- Identify Untrusted CA Certificates
- Repair Incomplete Certificate Chains
- Troubleshoot Pinned Certificates
- Troubleshoot Expired Certificates
- Troubleshoot Revoked Certificates
IKE Phase 2
Where Can I Use This? | What Do I Need? |
---|---|
| No license required |
After the tunnel is secured and authenticated, in Phase 2 the channel is further secured
for the transfer of data between the networks. IKE Phase 2 uses the keys that were
established in Phase 1 of the process and the IPSec Crypto profile, which defines the
IPSec protocols and keys used for the SA in IKE Phase 2.
The IPSec uses the following protocols to enable secure communication:
- Encapsulating Security Payload (ESP)—Allows you to encrypt the entire IP packet, and authenticate the source and verify the integrity of the data. While ESP requires that you encrypt and authenticate the packet, you can choose to only encrypt or only authenticate by setting the encryption option to Null; using encryption without authentication is discouraged.
- Authentication Header (AH)—Authenticates the source of the packet and verifies data integrity. AH doesn’t encrypt the data payload and is unsuited for deployments where data privacy is important. AH is commonly used when the main concern is to verify the legitimacy of the peer, and data privacy isn’t required.
ESP
|
AH
|
---|---|
Diffie-Hellman
(DH) exchange options supported
| |
| |
Encryption
algorithms supported
| |
|
(PAN-OS 10.1.0 and earlier releases) Data Encryption
Standard (DES) with the security strength of 56 bits.
|
|
Triple Data Encryption Standard (3DES) with a security strength of
112
bits.
|
|
Advanced Encryption Standard (AES) using cipher block chaining (CBC)
with a security strength of 128
bits.
|
|
AES using CBC with a security strength of 192
bits.
|
|
AES using CBC with a security strength of 256
bits.
|
|
AES using Counter with CBC-MAC (CCM) with a security strength of 128
bits.
|
|
AES using Galois/Counter Mode (GCM) with a security strength of 128
bits.
|
|
AES using GCM with a security strength of 256
bits.
|
Authentication
algorithms supported
| |
|
|
|
|
|
|
|
|
|
|
Methods of Securing IPSec VPN Tunnels (IKE Phase 2)
IPSec VPN tunnels can be secured using manual keys or auto keys. In addition, IPSec
configuration options include a Diffie-Hellman Group for key agreement, an
encryption algorithm, and a hash for message authentication.
- Manual Key—Manual key is typically used if the Palo Alto Networks firewall is establishing a VPN tunnel with a legacy device, or if you want to reduce the overhead of generating session keys. If using manual keys, the same key must be configured on both peers.Manual keys aren’t recommended for establishing a VPN tunnel because the session keys can be compromised when relaying the key information between the peers; if the keys are compromised, the data transfer is no longer secure.
- Auto Key— Auto Key allows you to generate keys automatically for setting up and maintaining the IPSec tunnel based on the algorithms defined in the IPSec Crypto profile.