From nobody Fri Oct 30 12:13:25 2020 Return-Path: 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 964CC3A1138; Fri, 30 Oct 2020 12:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 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, NICE_REPLY_A=-0.247, 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=iki.fi 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 8nLOMakDhyfm; Fri, 30 Oct 2020 12:13:17 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452B93A1136; Fri, 30 Oct 2020 12:13:14 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 173C71B006C6; Fri, 30 Oct 2020 21:13:11 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1604085191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UjR2qo96vBTRyNWg2Gtn7/LmpVRyTLAjfnby3eEkZMU=; b=ehBFyFR/zYMSl1IEnNe5Lz8ARDdEY8GZ2w++lzV9MYXvSzdY1K65sEX1deYgLX1pSxtaY+ fKz5GjmSNpI7juUAAvWKWiyaABDWquk1WmFHyf9M7GVg9AzRe0nrurGXNVBT0cTEtNJsU6 bkixfaiOS2riP8siOhwZ+p/+5/E+Aye2I+8fb6gSQUlHNY8eKPe4XCFpqzXfPP4s/YaV32 bGC1Be0zC3jfaDn0VGgVB1FgnG9baf8h++u5rzyZtNmudTl0zRmihmbDe7pZRvg81Ra8+s jbrMJVgmhowvB8hXA8wEK5O/iSLlgWSwVSybKuTVEW3/7F1XWYghSCEjDgqgZA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 129CB25C131D; Fri, 30 Oct 2020 21:13:09 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24476.26053.16496.150596@fireball.acr.fi> Date: Fri, 30 Oct 2020 21:13:09 +0200 From: Tero Kivinen To: Daniel Migault Cc: "Scott Fluhrer \(sfluhrer\)" , "ipsec\@ietf.org" , lwip@ietf.org In-Reply-To: References: X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1604085191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UjR2qo96vBTRyNWg2Gtn7/LmpVRyTLAjfnby3eEkZMU=; b=kqyn46QgOZ1+10VUUoWjCnDMGOPMRgEl47zSl9KChJ28qxysuCr2rEkJ+RlAV5iz+52rX+ QqA7FCY84/NmBhMJwuU79sQH3EoOrm/HNceZohDdW1KkSZnO33xxR9zx5p138DOvTgi/Wh oVWqAS/UOKQqA7WNul6Ku6Be9EIrap5M2c9pOMEoLpoQHOQlUV+E4NjExE/uHy3gbNG1p+ zGBQ1GgbQ5ERgCsz4gtGATyn6yUuDEYJ3zooBjHOuS7VNTfx0Lulr+845Vh44iGvl4U7wb 7Hy+pUgvRCaeanVUPchXHqSlweNm3pxttivxFvdLNofzoNx09N0qlonYwLemBQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1604085191; a=rsa-sha256; cv=none; b=m/PdhBmcZG1ralL2sW6OEJDP794RwZeya/hr0M4CUSTni2AC4PlxcWYYHGQAY+tBa770Qy u0PqGC6b2qUeaMgGhQX/mI1c54oTbQcnOAXrNRq+J/F4Uxe7BHLMpPf6uxxPHX9ttjQ+ls b9uAakM0capKtlh7gDqVTNRK1+8vppyEGmI+3y/8250dwjXCVvrIoVN5vHeSy3Q2prDguh O085swOpXwr0klNvTxvyg0TOGEh/Z3OxlhPaFdx3D+Kpddv1WeulvzGDjC17m4U2guPrqT GNSjQFE/LgP8+jlt+sLHFRlEFcYsUu3qH22P/Ga4I2tv5dtu4PqtinXWJyIplQ== Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 19:13:20 -0000 Daniel Migault writes: > The security consideration has been updated as follows: >=20 > """ > =C2=A0 The security of a communication provided by ESP is closely rel= ated 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 exam= ple.=C2=A0 When a > =C2=A0 =C2=A0node is provisioned with a session key that is used acro= ss reboot, > =C2=A0 =C2=A0the implementer MUST ensure that the mechanisms put in p= lace remain > =C2=A0 =C2=A0valid across reboot as well. >=20 > =C2=A0 =C2=A0It is RECOMMENDED to use ESP in conjunction of key manag= ement > =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 nego= tiate fresh > =C2=A0 =C2=A0session keys as well as prevent a session key being use = beyond its > =C2=A0 =C2=A0life time.=C2=A0 When such mechanisms cannot be implemen= ted and the > =C2=A0 =C2=A0session key is, for example, provisioned, the nodes SHOU= LD ensure > =C2=A0 =C2=A0that keys are not used beyond their life time and that t= he > =C2=A0 =C2=A0appropriated use of the key remains across reboots. Why the last sentence has SHOULD and not MUST=3F 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". > The use of fix SPI MUST NOT be considered as a way to avoid stron= g random > generators.=C2=A0 Such generator will be required in order to pro= vide strong > cryptographic protection=E2=80=9D; actually, if the IPsec impleme= ntation 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 requir= e random data > (CBC can be implemented securely without one), then the IPsec > implementation doesn=E2=80=99t actually need an CSPRNG. > =20 > > The current text presented it in another way. The former text seems t= o 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 >=20 > I am wondering how the IV is generated with CBC without random genera= tor.=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. --=20 kivinen@iki.fi