Re: [IPsec] Regarding ISAKMP SA lifetime negotiation.
"Anoop V A (anova)" <email@example.com> Mon, 04 March 2013 16:11 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9D21F84E8 for <firstname.lastname@example.org>; Mon, 4 Mar 2013 08:11:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([18.104.22.168]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7z7IS8cj8Rh for <email@example.com>; Mon, 4 Mar 2013 08:11:57 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [22.214.171.124]) by ietfa.amsl.com (Postfix) with ESMTP id 620FE21F8491 for <firstname.lastname@example.org>; Mon, 4 Mar 2013 08:11:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; email@example.com; 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-AV: E=Sophos;i="4.84,780,1355097600"; d="scan'208";a="183536238"
Received: from rcdn-core2-6.cisco.com ([126.96.36.199]) by rcdn-iport-3.cisco.com with ESMTP; 04 Mar 2013 16:11:57 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [188.8.131.52]) by rcdn-core2-6.cisco.com (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 xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x03.cisco.com ([184.108.40.206]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 10:11:56 -0600
From: "Anoop V A (anova)" <firstname.lastname@example.org>
To: Yoav Nir <email@example.com>, Tero Kivinen <firstname.lastname@example.org>
Thread-Topic: [IPsec] Regarding ISAKMP SA lifetime negotiation.
Date: Mon, 04 Mar 2013 16:11:56 +0000
References: <0E86FFD429E5FA4A97B86698F6C32AF81C271A91@xmb-rcd-x04.cisco.com> <email@example.com> <AE23EA6D-D6D2-43C1-AEBC-0D4F4A299B75@checkpoint.com>
Content-Type: text/plain; charset="us-ascii"
Cc: "firstname.lastname@example.org" <email@example.com>
Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation.
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:email@example.com?subject=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? Thanks Anoop -----Original Message----- From: Yoav Nir [mailto:firstname.lastname@example.org] Sent: Monday, March 04, 2013 9:30 PM To: Tero Kivinen Cc: Anoop V A (anova); email@example.com Subject: Re: [IPsec] Regarding ISAKMP SA lifetime negotiation. On Mar 4, 2013, at 4:31 PM, Tero Kivinen <firstname.lastname@example.org> 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. Yoav
- [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