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

Daniel Palomares <daniel.palomares.ietf@gmail.com> Thu, 06 March 2014 17:11 UTC

Return-Path: <daniel.palomares.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 D419D1A0083 for <ipsec@ietfa.amsl.com>; Thu, 6 Mar 2014 09:11:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUgcsaXaAe6w for <ipsec@ietfa.amsl.com>; Thu, 6 Mar 2014 09:11:07 -0800 (PST)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id EFC201A0048 for <ipsec@ietf.org>; Thu, 6 Mar 2014 09:11:06 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id lx4so3043593iec.38 for <ipsec@ietf.org>; Thu, 06 Mar 2014 09:11:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.50.143.12 with SMTP id sa12mr17216957igb.45.1394125863001; Thu, 06 Mar 2014 09:11:03 -0800 (PST)
Received: by 10.50.40.131 with HTTP; Thu, 6 Mar 2014 09:11:02 -0800 (PST)
In-Reply-To: <53184F65.6000201@gmail.com>
References: <CAHf5+hrQ52GPKsAZJF4ZyhFNXgwZJOTEm8u-KKqVbta6Bj=N1g@mail.gmail.com> <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> <CAHf5+hpJB6XUWR931vPWGdbsB-UNFa4F0k-5fF=4TG88ADMPSw@mail.gmail.com> <ED58B729FCA74D5AAF1A6520FB6D836A@buildpc> <53184F65.6000201@gmail.com>
Date: Thu, 6 Mar 2014 18:11:02 +0100
Message-ID: <CAHf5+ho1Uzr1-7gXZ_9G1CobOuBzU2gJzGcwhbXpOcp4kC3ahg@mail.gmail.com>
From: Daniel Palomares <daniel.palomares.ietf@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134cd02d622d804f3f33884
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/W5a9E3pf56YEiaBFn_5DKocArfs
Cc: IPsecme WG <ipsec@ietf.org>, Valery Smyslov <svanru@gmail.com>
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 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 <yaronf.ietf@gmail.com>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
>