topic Re: IKEv2 Proposal in Network Security

IKEv2 Proposal

MrBeginner — Sun, 27 Nov 2022 01:36:46 GMT

Hi,

i would like to ask about ikev2 proposal encryption. If we are using we encryption in IKEv2 proposal but i will use strong encryption on IPSec, can IKE proposal compromise ? Phase 1 will compromise ?

If Ike proposal is compromise, what kind of data will lose ?

what kind of information will attacker will get ?

Re: IKEv2 Proposal

Karsten Iwen — Sun, 27 Nov 2022 08:05:10 GMT

On the IKE SA both status messages are exchanged (think of it as a "management" tunnel) and also the key-negotiation of all following IPsec SAs are done.

It is best practice for the IKE SA to have at least the security strength of all IPsec SAs and also protect the additional IPsec SAs with PFS, Perfect Forward Secrecy.

Re: IKEv2 Proposal

MrBeginner — Sun, 27 Nov 2022 14:51:15 GMT

@Karsten Iwen ,

I cannot find any reference about below information.

If IKEv2 proposal is compromised , what will happen ?
It will only effect on ike proposal , it will not impact to payload,ipsec etc ?
It can see ipsec encrytion type,authentication type,preshare key ,etc ?

As per below thread, i concern malicious user can access to all data sent across the VPN connection, which may include passwords and sensitive file if ikev2 proposal is using weak encryption ?

https://community.cisco.com/t5/network-management/weak-ipsec-encryption/td-p/4093182

Re: IKEv2 Proposal

MHM Cisco World — Sun, 27 Nov 2022 14:47:39 GMT

I have note here,
what is different between phaseI and phaseII ??
PhaseI build protect tunnel to make PhaseII proposal exchange safely between two Peer.
so the hack must hack first Phase then he can know proposal, BUT the issue is key,
the key is not direct used it build from many seed info. include pre-shared key.
but can he predict the key used, YES

Re: IKEv2 Proposal

Karsten Iwen — Sun, 27 Nov 2022 17:52:31 GMT

The reference for all of this is the IKEv2 RFC (or the older RFCs for the legacy versions) ...
If at all, the IKE SA will get compromised, not the proposals. If an attacker can break the IKE SA, he will not automatically get the data from the IPsec SA, as all creations of the child SAs also include material from the initial Diffie-Hellman. And this can be even increase with the application of PFS which is optional, but can be considered as a best practice. But the attacker could read the additional exchanges which gives him an advantage.

The good thing is that with the actual RFC, every refresh of the IKE SA must also do an additional DH which was not mandated in previous RFCs.

The link that you quoted seems to be specific to weak algorithms like DES and DH1. For IKE/IPsec implementations all encryption that is not AES, all DH groups below DH14 and Hashing/HMACs below SHA2 are considered weak and should not be used any more.

Re: IKEv2 Proposal

MrBeginner — Mon, 28 Nov 2022 00:44:18 GMT

Hi @Karsten Iwen ,

As per your explanation ,If an attacker can break the IKE SA , they only can get ikev2 proposal information ( phase 1 ) , is it correct ? If we are using strong encryption/authentication on ipsec phase, they cannot see IPsec information ( phase2 ) .is it correct ?

Re: IKEv2 Proposal

Karsten Iwen — Mon, 28 Nov 2022 01:13:35 GMT

Basically yes, but ...

This is how the key-material for the IPsec SAs is build:

KEYMAT = prf+(SK_d, Ni | Nr)

If the IKE SA is broken, he sees the random nonces Ni and Nr that get exchanged for the next IPsec SA. But the attacker doesn't know the value of SK_d which is derived from the diffie-hellman exchange. But let's assume the worst case, we use a pseudo random function (PRF) of MD5 (what, of course, we never do), then the attacker could try to brute-force the next keys for the next SAs.

Re: IKEv2 Proposal

MrBeginner — Mon, 28 Nov 2022 02:21:54 GMT

Hi @Karsten Iwen ,

if we are using SHA 256 for key exchange , attacker will not get the information of ipsec or child_SA. And then If we are using PFS , key exchange will not use again same key .So attacker need to try again to get IKE SA after key life time is expire, is it correct ?

So let me know what is the best practice for key life time ?

Re: IKEv2 Proposal

Karsten Iwen — Mon, 28 Nov 2022 05:29:33 GMT

Correct. And breaking the IKE SA with AES256/AES128 is quite esoteric.

IMO, the default lifetimes on the Cisco devices (IKE one day, IPsec eight or one hour) is quite ok.

Re: IKEv2 Proposal

harryhales77 — Mon, 28 Nov 2022 06:04:53 GMT

Re: IKEv2 Proposal

Karsten Iwen — Mon, 28 Nov 2022 06:12:59 GMT

Correct

Re: IKEv2 Proposal

MHM Cisco World — Mon, 28 Nov 2022 08:40:02 GMT

he need time for his algorithm to break the Key, during that time the key is change.
why recommend strong ? if you see all strong hash&encrypt use long bits number for your example SHA256 meaning it use 256 bit, this long bit make hacker algorithm need more time and hence you are safe because in time he need to hack your info., you change seed of Key many times.

this in simple words why we need strong hash&encrypt in IPsec.

Re: IKEv2 Proposal

MrBeginner — Tue, 13 Dec 2022 15:02:59 GMT

Hi,

Let me know if IKE SA is compromised,attacker will get what kind of information?

How protect weakness encryption in phase 1,i knew that ipsece lvl ?

What information will include Ni and Nr ?

Re: IKEv2 Proposal

MrBeginner — Tue, 13 Dec 2022 15:05:57 GMT

Hi @MHM Cisco World

If ipsec tunbel is established, there is no more ikev2 phase one traffic?

Or ike SA will add in every ipsec packet ?

Re: IKEv2 Proposal

MHM Cisco World — Tue, 13 Dec 2022 15:14:58 GMT

friend, both Peers start clear text exchange proposal of phase1 and DH key seed
then after agree build tunnel 1, tunnel1 is secure by phase1 DH key and SA both peer use.

now phase2 start, both Peers exchange ID and proposal and PSK-Seed BUT this time this exchange is pass secure suing the tunnel1 build from phase1, and in end of this phase the two peers build tunnel2 which use to ass data traffic between two peer.

why I call it tunnel1 of phase1 ?? because when you do capture with wireshark you can see IP address of header but all data inside that packet is secure (encrypt).