cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8837
Views
10
Helpful
8
Replies

IPsec Client VPN - aggressive mode

marstoyanoff
Level 1
Level 1

Hi all,

I just got off the phone with customer that has passed a security scan check from a third party vendor. One of the vulnerebilities mentioned in the report is as follows:

udp_500.PNG

I know that only the IPsec client VPN uses aggressive mode to negotiate Phase I. So my question is how can I convince my customer to continue using the IPsec VPN? Is there anything I can do to reduce the risk of using this type of remote accesses. Also, am I having the same issue if I use SSL Client based VPN?

Regards,

Marty

2 Accepted Solutions

Accepted Solutions

olpeleri
Cisco Employee
Cisco Employee

Hello,

Ikev1 HUB running aggressive mode sends his PSK hash in the second packet along with his DH public value.

That's indeed a well-know protocol weakness.

To be able to act on that, U would have to be on the path to capture this flow in order to brute force the hash [ which is not obvious - but not impossible]

This issue is seriously mitigated by enabling XAUTH [User authentication].

Xauth is happening after DH , therefore under encryption.

Assuming strong password policy is in use, it's then very very very complex to find the right combination of user/password.

Ikev2 is way more secure in that regard and it's the right path.

Cheers,

Olivier

View solution in original post

8 Replies 8

malshbou
Level 1
Level 1

Hi,

IKE agressive mode has the well-known vulnerability of exchanging identities in cleartext.

You can use certificate authentication instead of pre-shared keys, or you can migrate to SSL VPN that doesn't have the agressive mode vulnerability.

Hope this helps

Mashal

------------------ Mashal Shboul

olpeleri
Cisco Employee
Cisco Employee

Hello,

Ikev1 HUB running aggressive mode sends his PSK hash in the second packet along with his DH public value.

That's indeed a well-know protocol weakness.

To be able to act on that, U would have to be on the path to capture this flow in order to brute force the hash [ which is not obvious - but not impossible]

This issue is seriously mitigated by enabling XAUTH [User authentication].

Xauth is happening after DH , therefore under encryption.

Assuming strong password policy is in use, it's then very very very complex to find the right combination of user/password.

Ikev2 is way more secure in that regard and it's the right path.

Cheers,

Olivier

Thank you guys!

Cheers

Marty

The links are fantastic. Thank Javier!

You are welcome!!

Please rate any helpful posts and mark this post as answered

Hello Javier,

I believe this vulnerability does not impact site to site VPNs.. specially when we are running over MPLS cloud instead of internet.. please confirm. I am facing a similar situation and need to present solution to customer security board.

Hello,

Yes you are correct. The reason for that is because LAN-to-LAN tunnels with pre-shared-keys use ISAKMP Main Mode.

So the key is protected during the exchange.

HTH.