Re: [Secdispatch] Controller-IKE

Eric Rescorla <ekr@rtfm.com> Mon, 22 July 2019 17:28 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF63F1202DE for <secdispatch@ietfa.amsl.com>; Mon, 22 Jul 2019 10:28:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 TvqmSqN5AAhz for <secdispatch@ietfa.amsl.com>; Mon, 22 Jul 2019 10:28:01 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D363E120336 for <secdispatch@ietf.org>; Mon, 22 Jul 2019 10:27:59 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id k18so38378876ljc.11 for <secdispatch@ietf.org>; Mon, 22 Jul 2019 10:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aR18sGsrus4/kqfzLVEarkKXKZF91EZn2R5GK9KH7tQ=; b=jbgGlDHmEKr73XKxRy9Z8tXjPu1FCcG5zh9VwVRortw9ZwNW9JzSXWf4RHUMbfVEuv IGUgkzjOj9XQZ5ZqzkeIf3UzulZbohwcwcrx8dwyohg1CJJZ1h/IV+CTK4Gf8nmbNQBf Rqu//UBxOL8lfq0vBblb8Vk2IpdrwKcDf+uGQksL8k/cSkj7pHUfz5MpnBki+q9n8jf2 bRo91RlI2o/TUrUk2KSSPxMa7D46Ntjco0IJWFk0su+Z/LOTsiUCM/McPSzqTKjwlt9T Q53BtGIcciRI+WD4zHjE2DNWJMCy+2idLtCHWeqOtoZgL1lb/HYjtj1C28AGjXQREFKc Z/4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aR18sGsrus4/kqfzLVEarkKXKZF91EZn2R5GK9KH7tQ=; b=oXRRgbOnq04fe0IOvtZgznQAngZZwhS3tFZ1RlqIKsuY2YCiwuLVFCabBG/rsmtwwE Dw4OypTSv0thF577aOuk3TTI8uDVIgQXgHKScjQgFEcZS/6HnRNH6xNDDjccI5hr8Iqc ko/L7Il/MKkvPhNJtrRvsXs0vT3GF8Rr4jFHycchYTpmvUHd4BWjNnvcrpgvrr29fa+b HL/T8tYGWH+PmrWdx8QU5z3nE1b3xkRe6UTggmfGuA5X5sYDJmsdosq5xss2iHSWXBMV l4WM/jxTA9Kp4W36zmOy8YgxWHrHHq9/5i3jYufiB67U2b1vwDlu8i4qCWRE5G1GTVf6 tAww==
X-Gm-Message-State: APjAAAXSeuzBd5W+YpVHJTkfmvaS/Qh4iqnszR7t/6pglJTIq/Nm/hRH 9sVsFpu202aos81farDRW8iRvcEoIIUEtLcsouRU4A==
X-Google-Smtp-Source: APXvYqxE/3g4aqEj9q1B933kv/Vb6+aooutlRZFCnVXqVe5L99fTwEQHdL51KGYlZ3PPuys69H0MeF7mVtI4QF2N8os=
X-Received: by 2002:a2e:b0e6:: with SMTP id h6mr35347862ljl.18.1563816477477; Mon, 22 Jul 2019 10:27:57 -0700 (PDT)
MIME-Version: 1.0
References: <CDF90625-34F6-40C3-8AE4-AACD50D70C2E@cisco.com> <CABcZeBOC6FPDe-PrfB4QKJoNVoOVYN_JuzteZE9GyrX0O_s2mg@mail.gmail.com> <698A5E01-5924-4D6C-9BD9-A8E87712086B@cisco.com> <CABcZeBMTeRuFQShONVAXOkaw6o=-0Jy4Pnrw8dHwwsFD+oBvfQ@mail.gmail.com> <23A860FA-61F4-4CD4-93DE-2FCE06984B9D@cisco.com>
In-Reply-To: <23A860FA-61F4-4CD4-93DE-2FCE06984B9D@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 22 Jul 2019 10:27:21 -0700
Message-ID: <CABcZeBNNZ8dWrksR+T+mXLzfGV9RemjoMHO0Q+s+TJV8p5ud8g@mail.gmail.com>
To: "David Carrel (carrel)" <carrel@cisco.com>
Cc: "secdispatch@ietf.org" <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a260a7058e486569"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/XOvy8P8z3xD1RrxHD-3S5bSa7D0>
Subject: Re: [Secdispatch] Controller-IKE
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 17:28:08 -0000

Thanks for clarifying. With that said, it's possible to do better than this
if you use a conventional AKE and time out associations somewhat
aggressively.

-Ekr




On Mon, Jul 22, 2019 at 10:09 AM David Carrel (carrel) <carrel@cisco.com>
wrote:

>
>
>
>
> * The PFS story here seems pretty bad: I'm assuming that people
> aren't going to change their DH keys very often (as it's extremely
> expensive for everyone else).
>
> True, the DH load can be expensive, but no more so than an equivalent mesh
> of traditional IKE.  We would not need to re-key any less often.  I believe
> this makes the PFS story equivalent.
>
> This doesn't seem correct to me. Consider the case where you do pairwise
> IKE and then delete the SA and the DH ephemerals. At this point, compromise
> doesn't leak the traffic keys at all. By contrast, in Controller-IKE
> because I need to store my DH share indefinitely in case a new peer comes
> online, then that represents a long-term source of compromise.
>
>
>
> OK, I think this is where you misunderstood something or we didn’t explain
> well enough.  There are no long-term DH keys in Controller-IKE.  All are
> ephemeral.  It is true that due to synchronization, you will likely keep
> them a little longer, but never more than 2 key lifetimes.  If you re-key
> every 2 hours, then the worst case is that your DH values are kept for 4
> hours.
>
>
>
> Dave
>
>
>