Re: [IPsec] Draft: IKEv2/IPsec Context Definition

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 06 March 2014 10:35 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8554C1A0249 for <ipsec@ietfa.amsl.com>; Thu, 6 Mar 2014 02:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CfgpcHPoCm1 for <ipsec@ietfa.amsl.com>; Thu, 6 Mar 2014 02:35:26 -0800 (PST)
Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 844811A01AF for <ipsec@ietf.org>; Thu, 6 Mar 2014 02:35:24 -0800 (PST)
Received: by mail-bk0-f46.google.com with SMTP id v15so635307bkz.33 for <ipsec@ietf.org>; Thu, 06 Mar 2014 02:35:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fr30XUacAncPMu2BMSAZdU2V0Bp1GMm6/I2DRIv5/Tk=; b=rA2RRzV9w9XJcR7udFS+MDjqijQWcMhMJwsaA5f2csKsIlXeoZTxF/vaiEo89y4rKC y//V24j5G8xV9GjE/Q/oiDzPWBZjDzyoCgna8WeEHjXbgLqmxgvxhR2AFmN4WJMtuaqG cIGMQUzLYRf2kEFA9Nk8qtnFjztVZlg1DDICBefF91MY5TAsXtW98f0KTOviergN31KX 5YH3MkzWmRvz6zVuxz8Bnl/AGzlKYSuLgiR79iNorAbFIRKi4KwnzHwP5lqz9SjhMHZl s47N+HlCMN7N5CY3smKee11//eTUo1LNX09djkihL58A/+/L7TltFKn8PJ1rNoMw9ONO cqHg==
X-Received: by 10.205.41.9 with SMTP id ts9mr180728bkb.61.1394102120115; Thu, 06 Mar 2014 02:35:20 -0800 (PST)
Received: from [10.2.0.25] (93-173-72-197.bb.netvision.net.il. [93.173.72.197]) by mx.google.com with ESMTPSA id ci7sm6765715bkc.0.2014.03.06.02.35.18 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 02:35:19 -0800 (PST)
Message-ID: <53184F65.6000201@gmail.com>
Date: Thu, 06 Mar 2014 12:35:17 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Valery Smyslov <svanru@gmail.com>, Daniel Palomares <daniel.palomares.ietf@gmail.com>
References: <CAHf5+hrQ52GPKsAZJF4ZyhFNXgwZJOTEm8u-KKqVbta6Bj=N1g@mail.gmail.com><7A4D82FA3EF546E499D0A0CD18C58153@buildpc> <CAHf5+hpJB6XUWR931vPWGdbsB-UNFa4F0k-5fF=4TG88ADMPSw@mail.gmail.com> <ED58B729FCA74D5AAF1A6520FB6D836A@buildpc>
In-Reply-To: <ED58B729FCA74D5AAF1A6520FB6D836A@buildpc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/PPAsKRPt81ermwR78JpVCxt43Ko
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 06 Mar 2014 10:35:27 -0000

> Sending SK_* is enough. Nonces are used only in calculations of SKEYSEED,
> SK_*, keymat for Child SA and AUTH payload content.Anyway, once the exchange
> is complete, the nonces, appeared in this exchange, may be discarded.
> Actually, you have 3 choices to exchange IKEv2 keying information
> between nodes in cluster:
> 1. Send your private DH key, peer's KE content and nonces. In this case
>      other nodes will recalculate all keys from the very beginning.
> 2. Send SKEYSEED and nonces.
> 3. Send computed SK_* keys. Note. that you even may omit sending SK_p*,
> as these
>      keys are used only during authentication (unless you implement
> Session Resumption,
>      but it also depends on how you store the tickets - by value or by
> reference).
> All approaches are equally possible. There seems to be some
> security and performance benefists for approach 3, but somebody
> may argue. Implementation may use any of this approaches
> and I don't think it's good to mandate the only approach,
> Regards,
> Valery.
>

Actually, I would suggest that we disallow (or "deprecate") option #1. 
IKEv2 explicitly allows for DH secrets to be shared between SAs (this is 
not a good idea, but people do it for performance reasons), and we even 
have an RFC to deal with the security issues resulting from this 
behavior. So a node would be sharing more than it bargained for.

Thanks,
	Yaron