[IPsec] Regarding ISAKMP SA lifetime negotiation.

Tero Kivinen <kivinen@iki.fi> Mon, 04 March 2013 14:31 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B8D1F21F8967 for <ipsec@ietfa.amsl.com>; Mon, 4 Mar 2013 06:31:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WPi7-mBT3dqI for <ipsec@ietfa.amsl.com>; Mon, 4 Mar 2013 06:31:54 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id CFC4821F8921 for <ipsec@ietf.org>; Mon, 4 Mar 2013 06:31:53 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r24EVi9x007617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Mar 2013 16:31:44 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r24EViRv013345; Mon, 4 Mar 2013 16:31:44 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20788.45136.1741.27834@fireball.kivinen.iki.fi>
Date: Mon, 04 Mar 2013 16:31:44 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Anoop V A (anova)" <anova@cisco.com>
In-Reply-To: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com>
References: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 12 min
X-Total-Time: 15 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: [IPsec] Regarding ISAKMP SA lifetime negotiation.
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2013 14:31:54 -0000

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

> 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

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

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