Re: [IPsec] Regarding ISAKMP SA lifetime negotiation.

"Anoop V A (anova)" <> Mon, 04 March 2013 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FD9D21F84E8 for <>; Mon, 4 Mar 2013 08:11:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v7z7IS8cj8Rh for <>; Mon, 4 Mar 2013 08:11:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 620FE21F8491 for <>; Mon, 4 Mar 2013 08:11:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4540; q=dns/txt; s=iport; t=1362413517; x=1363623117; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GD0SPZSYYfURLFPa0H89jKC77BJ5qCsqMm5J0GhnGHo=; b=I//kVz4Ue7EdDza11fiUglp2zAOn07NvSJGSDrUtuHbbkUxDeOdWKuHO lI3goOobary/gH4LkURyMlRc0btrEm2ig5MB6zDzZuFyTNYwqmCGm9/2M xQMaa3rbmRrp4i8TWlB1YiDT2DY0Bxyv2wV4VmurJAJrLbJDXI97Lga+A k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.84,780,1355097600"; d="scan'208";a="183536238"
Received: from ([]) by with ESMTP; 04 Mar 2013 16:11:57 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r24GBuii023815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 16:11:56 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 10:11:56 -0600
From: "Anoop V A (anova)" <>
To: Yoav Nir <>, Tero Kivinen <>
Thread-Topic: [IPsec] Regarding ISAKMP SA lifetime negotiation.
Thread-Index: Ac4Y4ESuGmhSbq0+TBy5np9wzLbTAf//5+wAgAAYwoD//92EoA==
Date: Mon, 04 Mar 2013 16:11:56 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation.
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Mar 2013 16:11:58 -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?


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

On Mar 4, 2013, at 4:31 PM, Tero Kivinen <> wrote:

> 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).

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.

>> 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...

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.

>> In short my questions are:
>> 1.       Can we send the responder life time notification in MM6 or
>>         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.

MM6 and AM2 are protected.

>> 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).

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.