Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00

Daniel Migault <mglt.ietf@gmail.com> Sun, 01 November 2020 20:41 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8FE3A0E84; Sun, 1 Nov 2020 12:41:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ml3r0ZpfVy83; Sun, 1 Nov 2020 12:41:35 -0800 (PST)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 DB75B3A0E81; Sun, 1 Nov 2020 12:41:34 -0800 (PST)
Received: by mail-vs1-xe34.google.com with SMTP id b4so6391822vsd.4; Sun, 01 Nov 2020 12:41:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RNSSlcnu5Ch1ViUKBT17OZlENvR65puCirbYRj85sBQ=; b=jJczrSTcM07BnrahwE86iHNtRIBRXRcBwtV5x59umhXR0ia+9IOV86Ycq2zC/W2q2A 7++z+vPs6o6xSwhoYtfTi6YU4pG0gQgBey4BA9Tasb0A/fIvBFb2B8QiGk0R7HBmDdHl 5d8MX6u6y/SedhbyKezI4DV+iOIQ6v0huN1IAEoUJVMCr+rzv71W0SeYqiarKmzSrWUJ 1wWfgZte4qwOs2378+tAYwtqoX0yE7JaBcZAoo3KCK32XZMQo11FD6RzN7y1KvcbXv36 EH8wZIZElSjnKwplG7cOSGS0b/kBKqHm4wozLz2opna+dfTkHkdpQudpFuMqnWO7H17K /HLQ==
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=RNSSlcnu5Ch1ViUKBT17OZlENvR65puCirbYRj85sBQ=; b=t/Bb7YsIZBHiPIt/w3qRTsQ+ZqhZIs9gtXam2blB4vrGq4PuoH5O5+khGQvsM42pRk cqUAWa5kOF78YICyhPIjVhRQtDptKRwEgWwtPKZKjS5mOgzi7VPLnufMCVW4xdWrXzuC 81XLGsnNWtJKKTWXYgti6c4sHuakY8hOD9ZqEHZVq8qajVdi0Dj4CAodmyilZFkC+pE6 tIaLC2uGgWDhCqEICSAwXoUZC4Yj6+nSqr5SMXTiHDOXNaCQ5VVavsS/5FEtbi2NW7Uy hJtfADnnw78GHCSZa+Tqw3+r1cHDzEIikBMOn0iJeyEctKlJ+E7jnCM1VWrTdUWs8Da+ bLVg==
X-Gm-Message-State: AOAM531zICIFiLX8wu18iUmG3eXSGVRpEVJpYYaFu9Vyk/b3EZBGcsSS BNBALPjY0b4Cqpn+sQavFmmU0r4Jdz+rjOwLpyo=
X-Google-Smtp-Source: ABdhPJy6vP3+s8Vm2ofjVB2ztH4ORoBlMld3hDrENBYsKe8OJC9quyLC+IcwTtpfGnVtwnYng0VOE/8+K7JpD3O/U4A=
X-Received: by 2002:a05:6102:309a:: with SMTP id l26mr243186vsb.4.1604263293988; Sun, 01 Nov 2020 12:41:33 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR11MB3871D71922DC05E087BDF992C1C40@MN2PR11MB3871.namprd11.prod.outlook.com> <CADZyTkn-sn9Txfj9R9j8o97jKwrkcRWkfLrvsu4WkZ-WHkVNKA@mail.gmail.com> <24476.26053.16496.150596@fireball.acr.fi>
In-Reply-To: <24476.26053.16496.150596@fireball.acr.fi>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Sun, 01 Nov 2020 15:41:23 -0500
Message-ID: <CADZyTkmTr3jna3_=j__s=yYw4PXJ6mrO7hoNp=Zp+Are56Y8EA@mail.gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Cc: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, "ipsec@ietf.org" <ipsec@ietf.org>, lwip@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c3b2bb05b311a7f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/us6a9QncM4Z8AatbpKdkNIrWDmE>
Subject: Re: [Lwip] [IPsec] Comments on draft-ietf-lwig-minimal-esp-00
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Nov 2020 20:41:37 -0000

Hi Tero,

Thanks for the comments. Please find below how I updated the text on my
local copy and let me know if that addresses your concerns.

Yours,
Daniel

On Fri, Oct 30, 2020 at 3:13 PM Tero Kivinen <kivinen@iki.fi> wrote:

> Daniel Migault writes:
> > The security consideration has been updated as follows:
> >
> > """
> >   The security of a communication provided by ESP is closely related to
> >    the security associated to the management of that key.  This usually
> >    include mechanisms to prevent a nonce to repeat for example.  When a
> >    node is provisioned with a session key that is used across reboot,
> >    the implementer MUST ensure that the mechanisms put in place remain
> >    valid across reboot as well.
> >
> >    It is RECOMMENDED to use ESP in conjunction of key management
> >    protocols such as for example IKEv2 [RFC7296] or minimal IKEv2
> >    [RFC7815].  Such mechanisms are responsible to negotiate fresh
> >    session keys as well as prevent a session key being use beyond its
> >    life time.  When such mechanisms cannot be implemented and the
> >    session key is, for example, provisioned, the nodes SHOULD ensure
> >    that keys are not used beyond their life time and that the
> >    appropriated use of the key remains across reboots.
>
> Why the last sentence has SHOULD and not MUST? If device reuses the
> key across reboots and the algorithm is counter mode based, this will
> cause serious security issues. Also same thing happens if the counters
> are allowed to roll over. I would suggest changing that "MUST ensure".
>
<mglt>
Correct. it must be a  MUST. I also explicitly added that condition on
nonce and counter needs to remain valid. The new text is as follows:

When such mechanisms cannot be implemented and the session key is, for
example, provisioned, the nodes MUST ensure that keys are not used beyond
their life time and that the appropriate use of the key remains across
reboots - e.g. conditions on counters and nonces remains valid.

</mglt>

>
> >     The use of fix SPI MUST NOT be considered as a way to avoid strong
> random
> >     generators.  Such generator will be required in order to provide
> strong
> >     cryptographic protection”; actually, if the IPsec implementation
> doesn’t
> >     actually generate its own keys (that is, it relies on an external
> service
> >     to provide them), and the transform itself doesn’t require random
> data
> >     (CBC can be implemented securely without one), then the IPsec
> >     implementation doesn’t actually need an CSPRNG.
> >
> > <mglt>
> > The current text presented it in another way. The former text seems to
> explain
> > that random was necessary for the generation of SPI. The current text
> has been
> > updated to explain that we may have nodes without random generators.
> >
> > I am wondering how the IV is generated with CBC without random
> generator.
>
> Normally you use just counter, and encrypt it with secret key. The IV
> in CBC does not be random, it needs to be unpredictable and it should
> not be direct counter or other source with low Hamming distance
> between successive IVs.
>
> Actually the problem with old way of CBC mode was that the IV was
> random, but predictable as implementations used last block of previous
> packet. If attacker does not know the key you are using to encrypt the
> counter to generate IVs, the IVs will be unpredictable and random.
>
<mglt>
Thanks for the information. What I was wondering then, is for which reason
can't we consider this as a random generator - of a limited lifetime.
</mglt>

> --
> kivinen@iki.fi
>


-- 
Daniel Migault
Ericsson