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

Yaron Sheffer <> Thu, 06 March 2014 10:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8554C1A0249 for <>; Thu, 6 Mar 2014 02:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6CfgpcHPoCm1 for <>; Thu, 6 Mar 2014 02:35:26 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4008:c01::22e]) by (Postfix) with ESMTP id 844811A01AF for <>; Thu, 6 Mar 2014 02:35:24 -0800 (PST)
Received: by with SMTP id v15so635307bkz.33 for <>; Thu, 06 Mar 2014 02:35:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id ts9mr180728bkb.61.1394102120115; Thu, 06 Mar 2014 02:35:20 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id ci7sm6765715bkc.0.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 02:35:19 -0800 (PST)
Message-ID: <>
Date: Thu, 06 Mar 2014 12:35:17 +0200
From: Yaron Sheffer <>
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 <>, Daniel Palomares <>
References: <><7A4D82FA3EF546E499D0A0CD18C58153@buildpc> <> <ED58B729FCA74D5AAF1A6520FB6D836A@buildpc>
In-Reply-To: <ED58B729FCA74D5AAF1A6520FB6D836A@buildpc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPsecme WG <>
Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.