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

Daniel Palomares <> Thu, 06 March 2014 17:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D419D1A0083 for <>; Thu, 6 Mar 2014 09:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UUgcsaXaAe6w for <>; Thu, 6 Mar 2014 09:11:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::233]) by (Postfix) with ESMTP id EFC201A0048 for <>; Thu, 6 Mar 2014 09:11:06 -0800 (PST)
Received: by with SMTP id lx4so3043593iec.38 for <>; Thu, 06 Mar 2014 09:11:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wjU3HHh5vBhnI0x2vC4m/XmLJpfKL6lQqZM4i6R+ksM=; b=Tin/DMkA2qC6H6ekeK/W+MX+EtKG5ArP+g8mLQq5v08z221oIXmCjjDWb67I5XrpSW 7yzYbhCAf9wtrrploV/FnwrfGZZQ1bMZcEVquNzXRdZHPqIZuc6kPQ9YMk6xJrIgkBuG 6FERE5+OhIce4TkIwqGtV6URTvChxxh3xIN7ZvtE8rm6HSr2b/jU0SEaqvhrzFx98Nna P/7Hy7SM61sxCAyIvcoAskwDPsf2Kv4Wogkf5fd7MGQXMT9gV1PWub+/AaRNIBrtlNvC 3PfC7lV7MbReNj6aK4ds/IM1h+DDnYSU/8ucZL78OgNWnKzzcVvkIuihCCJn726zdQn3 6erQ==
MIME-Version: 1.0
X-Received: by with SMTP id sa12mr17216957igb.45.1394125863001; Thu, 06 Mar 2014 09:11:03 -0800 (PST)
Received: by with HTTP; Thu, 6 Mar 2014 09:11:02 -0800 (PST)
In-Reply-To: <>
References: <> <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> <> <ED58B729FCA74D5AAF1A6520FB6D836A@buildpc> <>
Date: Thu, 6 Mar 2014 18:11:02 +0100
Message-ID: <>
From: Daniel Palomares <>
To: Yaron Sheffer <>
Content-Type: multipart/alternative; boundary=001a1134cd02d622d804f3f33884
Cc: IPsecme WG <>, Valery Smyslov <>
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 17:11:10 -0000

Hi Yaron,

Thanks for the comments.

Yeah, I have seen one application that implements High Availability by
sending DH secret + KE + Nonces.
Concerning the RFC that deals with the security issues resulting from this
behavior, are you talking about  Yoav's RFC - IPsec Cluster Statement?. If
not, could you please tell me which RFC are you mentioning?

 So, as this is a known issue (Case #1), there is no problem to disallow it.

Other point from previous discussions:
I just wanted to add that in the Case #3, Valery and I had some offline
discussions about it, and we found out that actually the SK_p*_old are not
used to compute Session Resumption's AUTH payload. Instead, SK_d_old is
used to compute it. This means that we actually can avoid SK_p*  to be
included in the IKE_SA Context Parameters (with a Mandatory flag). If
anyone thinks SK_p* might be needed for some other exchange, please point
that out through the mailing-list.

Thank you,

Kind Regards,
Daniel Palomares

2014-03-06 11:35 GMT+01:00 Yaron Sheffer <>om>:

> 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