Subject: [IPsec] Regarding ISAKMP SA lifetime negotiation.

From: "Anoop V A (anova)" <[email-masked]>
Date: Mon, 4 Mar 2013 13:57:58 +0000

Hello experts,

   I have a generic doubt regarding the ISAKMP SA(phase 1) life time negotiation. My  query is can we agree up on the  ISAKMP life time in the first two messages of MM or AM.

What I want to know is  - the life time is sent as an proposal attribute in the first two messages of Main mode and aggressive mode. We are not negotiating the parameter so if the responder is having a less life time value configured - then can we transfer this info in the MM2 or AM2 message from the responder along with the negotiated proposal attributes. Basically I am trying to change the life time attribute sent by the initiator - in this scenario.

We have the responder life time notify mechanism as per the draft (draft-ietf-ipsec-ike-lifetime-00), but the separate notify messages are not reliable in IKEv1(Uni directional)

In short my questions are:

1.       Can we send the responder life time notification in MM6 or AM2 message from the responder?

2.       Or can we alter the life time attribute of the ISAKMP SA proposal offer?( Is this considers as  a violation of the RFC)

Thanks
Anoop

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 Mar 2013 16:31:44 +0200

Anoop V A (anova) writes:
> 
> Hello experts,
> 
>    I have a generic doubt regarding the ISAKMP SA(phase 1) life time
>    negotiation. My  query is can we agree up on the  ISAKMP life
>    time in the first two messages of MM or AM. 
> 
> What I want to know is  - the life time is sent as an proposal
> attribute in the first two messages of Main mode and aggressive
> mode. We are not negotiating the parameter so if the responder is
> having a less life time value configured - then can we transfer this
> info in the MM2 or AM2 message from the responder along with the
> negotiated proposal attributes. Basically I am trying to change the
> life time attribute sent by the initiator - in this scenario. 

Anything extra (notifications etc) you send inside the main mode or
agressive mode packets are not authenticated, so sending responder
life time notifications is not good idea (and the other end will
simply ignore it).

> We have the responder life time notify mechanism as per the draft
> (draft-ietf-ipsec-ike-lifetime-00), but the separate notify messages
> are not reliable in IKEv1(Uni directional)

That is expired very old draft that did not get forward, there is no
point of implementing that... 

>          AM2 message from the responder?

You can, but most likely all implementations will ignore them, and
if any implementation does not ignore them, that opens attack where
attacker can shorten the lifetime at will by just adding such
notification. 

> 2.       Or can we alter the life time attribute of the ISAKMP SA
>          proposal offer?( Is this considers as  a violation of the
>          RFC)

That is considered violation of the RFC, thus all complient
implemnetations will reject the proposal. RFC2408 section 4.2 Security
Association Establishment last paragraph:

								The
   initiator MUST verify that the Security Association payload received
   from the responder matches one of the proposals sent initially.

Easy answer to all of your questions is to NOT use the protocol that
was obsoleted more than 7 years ago (IKEv1 was obsoleted by IKEv2 in
2005), and instead start to use current version of the protocol i.e
IKEv2, which already solves those problem (the notifications are
authenticated, the lifetimes are removed and moved to local matter,
the informational exchanges are reliable etc).
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Mar 2013 16:00:22 +0000

> life time notifications is not good idea (and the other end will

This is true for MM2, but not for MM6. MM6 is encrypted and authenticated, so the peer can and should (if they implemented the draft) use it.

> point of implementing that... 

It makes sense for working with implementations where you can't configure such parameters, like VPN clients. Sadly, none of the generic IKEv1-using clients (like the L2TP clients) seem to support this draft.

> attacker can shorten the lifetime at will by just adding such

MM6 and AM2 are protected.

> the informational exchanges are reliable etc).

Now that I agree with. This draft addresses one deficiency in IKEv1. The reason to support IKEv1 today is to support legacy implementations. I don't think anyone is adding this feature now to legacy implementations. So yes, <hat type="vendor"> Check Point code supports it, but </hat> it's better to use IKEv2 where interoperability with different configured lifetimes has been shown to work.

Yoav

---

From: "Anoop V A (anova)" <[email-masked]>
Date: Mon, 4 Mar 2013 16:11:56 +0000

Hi Yoav/Kivinen

    Thanks a lot for your quick response.  As  Yoav said - this is for the  some legacy solution support - there in some strange situation we are ending up with different lifetime in the boxes, and creating some issues.
So now as to add to the same question -

 If we are sending the extra IKE responder life time notification in MM6 or AM2 - since the peer AUTHENTICATION data is also available in these messages - can we overcome this situation. We can avoid attack by changing the life time only if the authentication is successful.

I understand may be other implementation will avoid this extra notify - but is there any violation in sending this extra notify in these messages?

Thanks
Anoop

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Monday, March 04, 2013 9:30 PM
To: Tero Kivinen
Cc: Anoop V A (anova); [email-masked]
Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation.

On Mar 4, 2013, at 4:31 PM, Tero Kivinen <[email-masked]> wrote:

>> attribute in the first two messages of Main mode and aggressive mode. 
>> We are not negotiating the parameter so if the responder is having a 
>> less life time value configured - then can we transfer this info in 
>> the MM2 or AM2 message from the responder along with the negotiated 
>> proposal attributes. Basically I am trying to change the life time 
>> attribute sent by the initiator - in this scenario.
> 

> You can, but most likely all implementations will ignore them, and if 
> any implementation does not ignore them, that opens attack where 

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Mar 2013 12:40:36 +0200

Yoav Nir writes:
> This is true for MM2, but not for MM6. MM6 is encrypted and
> authenticated, so the peer can and should (if they implemented the
> draft) use it.

MM6 is encrypted, but not authenticated, except for certain parts
inside the packet. The MM5/MM6 do have SIG (certificates)/HASH
(pre-shared keys) payload, but that only covers certain parts:

    HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
    HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )

So if original MM5/MM6 has notification payload and attacker can guess
where it is (not very hard), he can modify it (even when it is
encrypted).

This is one of the things we did fix in the IKEv2, and thats why IKEv2
do MAC all of the payloads, and the authentication hash do include the
whole IKE_SA_INIT packet so it also gets authenticated.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Mar 2013 13:34:08 +0200

Anoop V A (anova) writes:
>  If we are sending the extra IKE responder life time notification in
>  MM6 or AM2 - since the peer AUTHENTICATION data is also available
>  in these messages - can we overcome this situation. We can avoid
>  attack by changing the life time only if the authentication is
>  successful.

As I pointed out earlier, attacker can MODIFY the notification data,
so they can change the life time stored inside the notification data
(there are some difficulties there, but lets not go to them). On the
other hand you would never accept any lifetime that would not be
accordingly to your own policy anyways, so this attack isn't that
effective in this case, as attacker can only change lifetime to
something that you would otherwise accept. So in worst case you are in
the same situation you were without this notification.

> I understand may be other implementation will avoid this extra
> notify - but is there any violation in sending this extra notify in
> these messages? 

Most likely they will ignore the extra notify, but to be safe it might
be better to add vendor id payloads and only send notify if the other
end is sending known vendor id. There are some quite bad IKEv1
implementations out there, and I would not even try to guess what they
might do when they get extra notification payloads.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Mar 2013 12:09:21 -0500 (EST)

> might do when they get extra notification payloads.

I already see some different vendorids for this coming in at times.

The openswan/libreswan implementations ignore this vid, however I have
been thinking about trying to make use of it on the initiator. It is
useful if the responder is set to never rekey. If you don't take their
lifetime into account, the IPsec SA can silently die (Cisco does this to me)
if their lifetime is shorter. Or the remote could send a Delete/Notify and
then the tunnel could be briefly down while the initiator re-initiates.

The work around now is to ensure to set the keylife shorter on the
initiator so you avoid these issues, but that requires manual and per
case configuration.

Paul