[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [127.0.0.1]) 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 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). -- kivinen@iki.fi
- [IPsec] Regarding ISAKMP SA lifetime negotiation. Anoop V A (anova)
- [IPsec] Regarding ISAKMP SA lifetime negotiation. Tero Kivinen
- Re: [IPsec] Regarding ISAKMP SA lifetime negotiat… Yoav Nir
- Re: [IPsec] Regarding ISAKMP SA lifetime negotiat… Anoop V A (anova)
- Re: [IPsec] Regarding ISAKMP SA lifetime negotiat… Tero Kivinen
- Re: [IPsec] Regarding ISAKMP SA lifetime negotiat… Tero Kivinen
- Re: [IPsec] Regarding ISAKMP SA lifetime negotiat… Paul Wouters