From nobody Sun Nov 1 12:41:40 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@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: <24476.26053.16496.150596@fireball.acr.fi> In-Reply-To: <24476.26053.16496.150596@fireball.acr.fi> From: Daniel Migault Date: Sun, 1 Nov 2020 15:41:23 -0500 Message-ID: To: Tero Kivinen Cc: "Scott Fluhrer (sfluhrer)" , "ipsec@ietf.org" , lwip@ietf.org Content-Type: multipart/alternative; boundary="000000000000c3b2bb05b311a7f4" Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 20:41:37 -0000 --000000000000c3b2bb05b311a7f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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". > 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. > > > 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=E2=80=9D; actually, if the IPsec implement= ation > doesn=E2=80=99t > > actually generate its own keys (that is, it relies on an external > service > > to provide them), and the transform itself doesn=E2=80=99t require = random > data > > (CBC can be implemented securely without one), then the IPsec > > implementation doesn=E2=80=99t actually need an CSPRNG. > > > > > > 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. > 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. > -- > kivinen@iki.fi > --=20 Daniel Migault Ericsson --000000000000c3b2bb05b311a7f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tero,=C2=A0

<= div>Thanks for the comments. Please find=C2=A0below how I updated the text = on my local copy and let me know if that addresses your concerns.=C2=A0

Yours,=C2=A0
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:
>
> """
> =C2=A0 The security of a communication provided by ESP is closely rela= ted to
> =C2=A0 =C2=A0the security associated to the management of that key.=C2= =A0 This usually
> =C2=A0 =C2=A0include mechanisms to prevent a nonce to repeat for examp= le.=C2=A0 When a
> =C2=A0 =C2=A0node is provisioned with a session key that is used acros= s reboot,
> =C2=A0 =C2=A0the implementer MUST ensure that the mechanisms put in pl= ace remain
> =C2=A0 =C2=A0valid across reboot as well.
>
> =C2=A0 =C2=A0It is RECOMMENDED to use ESP in conjunction of key manage= ment
> =C2=A0 =C2=A0protocols such as for example IKEv2 [RFC7296] or minimal = IKEv2
> =C2=A0 =C2=A0[RFC7815].=C2=A0 Such mechanisms are responsible to negot= iate fresh
> =C2=A0 =C2=A0session keys as well as prevent a session key being use b= eyond its
> =C2=A0 =C2=A0life time.=C2=A0 When such mechanisms cannot be implement= ed and the
> =C2=A0 =C2=A0session key is, for example, provisioned, the nodes SHOUL= D ensure
> =C2=A0 =C2=A0that keys are not used beyond their life time and that th= e
> =C2=A0 =C2=A0appropriated 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&q= uot;.
<mglt>
Correct. it must be a=C2= =A0 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 lif= e time and that the appropriate use of the key remains across reboots - e.g= . conditions on counters and nonces remains valid.

=
</mglt>=C2=A0

>=C2=A0 =C2=A0 =C2=A0The use of fix SPI MUST NOT be considered as a way = to avoid strong random
>=C2=A0 =C2=A0 =C2=A0generators.=C2=A0 Such generator will be required i= n order to provide strong
>=C2=A0 =C2=A0 =C2=A0cryptographic protection=E2=80=9D; actually, if the= IPsec implementation doesn=E2=80=99t
>=C2=A0 =C2=A0 =C2=A0actually generate its own keys (that is, it relies = on an external service
>=C2=A0 =C2=A0 =C2=A0to provide them), and the transform itself doesn=E2= =80=99t require random data
>=C2=A0 =C2=A0 =C2=A0(CBC can be implemented securely without one), then= the IPsec
>=C2=A0 =C2=A0 =C2=A0implementation doesn=E2=80=99t actually need an CSP= RNG.
>=C2=A0 =C2=A0
> <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.= =C2=A0
>
> I am wondering how the IV is generated with CBC without random generat= or.=C2=A0

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.=C2=A0
</mglt>=C2=A0
--
kivinen@iki.fi


--
Daniel Migault
Ericsson
--000000000000c3b2bb05b311a7f4--