Monthly Archives: December 2013

About Diffie-Hellman Groups

Posted on by
Reply
About Diffie-Hellman Groups

Diffie-Hellman (DH) groups determine the strength of the key used in the key exchange process. Higher group numbers are more secure, but require additional time to compute the key.

Firebox or XTM devices support Diffie-Hellman groups 1, 2, and 5:

  • DH Group 1: 768-bit group
  • DH Group 2: 1024-bit group
  • DH Group 5: 1536-bit group

Both peers in a VPN exchange must use the same DH group, which is negotiated during Phase 1 of the IPSec negotiation process. When you define a manual BOVPN tunnel, you specify the Diffie-Hellman group as part of Phase 1 of creating an IPSec connection. This is where the two peers make a secure, authenticated channel they can use to communicate.

DH groups and Perfect Forward Secrecy (PFS)

In addition to Phase 1, you can also specify the Diffie-Hellman group in Phase 2 of an IPSec connection. Phase 2 configuration includes settings for a security association (SA), or how data packets are secured when they are passed between two endpoints. You specify the Diffie-Hellman group in Phase 2 only when you select Perfect Forward Secrecy (PFS).

PFS makes keys more secure because new keys are not made from previous keys. If a key is compromised, new session keys are still secure. When you specify PFS during Phase 2, a Diffie-Hellman exchange occurs each time a new SA is negotiated.

The DH group you choose for Phase 2 does not need to match the group you choose for Phase 1.

How to Choose a Diffie-Hellman Group

The default DH group for both Phase 1 and Phase 2 is Diffie-Hellman Group 1. This group provides basic security and good performance. If the speed for tunnel initialization and rekey is not a concern, use Group 2 or Group 5. Actual initialization and rekey speed depends on a number of factors. You might want to try DH Group 2 or 5 and decide whether the slower performance time is a problem for your network. If the performance is unacceptable, change to a lower DH group.

Performance Analysis

The following table shows the output of a software application that generates 2000 Diffie-Hellman values. These figures are for a 1.7GHz Intel Pentium 4 CPU.

DH Group No. of key pairs Time required Time per key pair
Group 1 2000 43 sec 21 ms
Group 2 2000 84 sec 42 ms
Group 5 2000 246 sec 123 ms

Dead Peer Detection – DPD on routers

Posted on by
Reply

Cisco routers support two DPD types: On-demand DPD and Periodic DPD:

crypro isakmp keepalive <threshold> <retry-interval> {[on-demand] | periodic}

In case of on-demand DPD a router sends its R-U-THERE message to a peer if there is a traffic to send to the peer and the peer was idle for <threshold> seconds (i.e. there was no traffic from the peer for <threshold> seconds). On-demand DPD was introduced in IOS 12.2(8)T and the implementation has changed multiple times since then.

In case of periodic DPD a router sends its R-U-THERE messages at regular intervals. It doesn’t take into consideration traffic coming from peer. This is the only Cisco platform that supports true periodic DPD. Periodic DPD was introduced in IOS 12.3(7)T and the implementation has changed multiple times since then.

Specifically, in the DDTS CSCin76641 (IOS 12.3(09.08)T) a decision was made to not send R-U-THERE request when the periodic DPD is configured and a traffic is received from the peer. Finally, it has reverted to the original behavior. See DDTS CSCsh12853(12.4(13.11)T 12.4(11)T02 12.4(09)T05 12.4(06)T08) for details.

Periodic DPD can improve convergence in some scenarios.

DPD is disabled by default on Cisco routers. The default mode is “on-demand” if not specified.

If the peer doesn’t respond with the R-U-THERE-ACK the router starts retransmitting R-U-THERE messages every <retry-interval>seconds with a maximum of five retransmissions. After that the peer is declared dead.

You cannot specify the number of retries on Cisco routers.

Also, it is possible to configure DPD in ISAKMP profiles. The caveat, however, is that there are no “periodic” and “on-demand”configuration options. So, the ISAKMP profile will inherit global setting. I.e., if you enable periodic DPD globally, all your ISAKMP profiles will operate in “periodic” DPD mode with profile-specific DPD timers.

crypto isakmp profile QQQ
 keepalive <interval> retry <retry-interval>

Another caveat is that you cannot disable DPD completely. DPD is always negotiated, even if not configured or disabled in ISAKMP profile with “no keepalive”. In this case the router will answer DPD requests with R-U-THERE-ACK, but will not initiate DPD requests with R-U-THERE (“one-way” mode).

In brief, on routers we have the following:

  • true periodic DPD and on-demand DPD
  • DPD cannot be completely disabled
  • one-way mode is supported and is the default mode
  • retry interval can be configured
  • retry count cannot be configured and equals to five

Dead Peer Detection – DPD on ASA

Posted on by
Reply

ASA and PIX firewalls support “semi-periodic” DPD only. I.e. they send R-U-THERE message to a peer if the peer was idle for<threshold> seconds. ASA may have nothing to send to the peer, but DPD is still sent if the peer is idle. If the VPN session is comletely idle the R-U-THERE messages are sent every <threshold> seconds. If there is a traffic coming from the peer the R-U-THERE messages are not sent.

Unlike routers, you can completely disable DPD on ASA and it will not negotiate it with a peer (“disable” configuration option).

Also, you can configure “one-way” DPD mode on ASA. The ASA will respond to R-U-THERE messages, but will not initiate DPD exchange (“threshold infinite” configuration option).

isakmp keepalive {disable | threshold <threshold> retry <retry-interval> | threshold infinite}

If the peer doesn’t respond with the R-U-THERE-ACK the ASA starts retransmitting R-U-THERE messages every <retry-interval>seconds with a maximum of three retransmissions. After that the peer is declared dead.

You cannot specify the number of retries on ASA.

DPD is enabled by default on ASA for both L2L and RA IPSec:

tunnel-group DefaultL2LGroup ipsec-attributes
 isakmp keepalive threshold 10 retry 2
tunnel-group DefaultRAGroup ipsec-attributes
 isakmp keepalive threshold 300 retry 2

In brief, on ASA we have the following:

  • only “semi-periodic” DPD is supported
  • DPD can be completely disabled
  • one-way mode is supported
  • bidirectional mode is the default one
  • retry interval can be configured
  • retry count cannot be configured and equals to three

PFS (Perfect Forward Secrecy)

Posted on by
Reply

PFS will ensure the same key will not be generated again, so forcing a new diffie-hellman key exchange. This would ensure if a hacker\criminal was to compromise a private key, they would only be able to access data in transit protected by that key and not any future data, as future data would not be associated with that compromised key.

PFS is enabled on an ASA with the crypto map set pfs command.

Both sides of the VPN must be able to support PFS in order for PFS to work. When PFS is turned on, for every negotiation of a new phase 2 SA the two gateways must generate a new set of phase 1 keys. This is an extra layer of protection that PFS adds, which ensures if the phase 2 SA’s have expired, the keys used for new phase 2 SA’s have not been generated from the current phase 1 keying material. Of course if PFS is not turned on then the current keying material already established at phase 1 will be used again to generate phase 2 SA’s.

Therefore using PFS provides a more secure VPN connection. Although using PFS does have its drawback. It will require more processing power, and take slightly longer for phase 1 and 2 to complete. PFS in general is known as a session key. A session key is a key just created for a particular session, and when the session is bought down, the key is destroyed and not used again. Next time a session is initiated a new and completely different session key is created.

You don’t have to use PFS if you don’t want to, just leave it disabled. However if you are protecting very sensitive data then maybe it should be enabled. It depends on your requirements and security policies. It depends on how sensitive your data is and how often you would like to renew these keys. What is the worst that could happen if a criminal did get their hands on this sensitive data? This should give you a good indication to whether you should have it enabled and for how long each key is renewed or disabled. Just remember having it enabled and renewing keys more often will have a little performance impact but provide further security.

So in a nutshell leaving PFS on will improve security forcing a new key exchange. It does this every so often depending on the configured time settings.