Re: [IPsec] Regarding ISAKMP SA lifetime negotiation.

Tero Kivinen <> Tue, 05 March 2013 11:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 537AA21F8923 for <>; Tue, 5 Mar 2013 03:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.149
X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DwZDNvhPNNlk for <>; Tue, 5 Mar 2013 03:34:22 -0800 (PST)
Received: from ( [IPv6:2001:1bc8:100d::2]) by (Postfix) with ESMTP id 8A89B21F88E6 for <>; Tue, 5 Mar 2013 03:34:21 -0800 (PST)
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id r25BY9OG009590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Mar 2013 13:34:09 +0200 (EET)
Received: (from kivinen@localhost) by (8.14.5/8.12.11) id r25BY8p9018906; Tue, 5 Mar 2013 13:34:08 +0200 (EET)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 05 Mar 2013 13:34:08 +0200
From: Tero Kivinen <>
To: "Anoop V A (anova)" <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 6 min
X-Total-Time: 5 min
Cc: "" <>, Yoav Nir <>
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: Tue, 05 Mar 2013 11:34:22 -0000

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.