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

From: Daniel Migault <[email-masked]>
Date: Sun, 1 Nov 2020 15:41:23 -0500

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 <[email-masked]> 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>

> --
> [email-masked]

-- 
Daniel Migault
Ericsson

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 2 Nov 2020 16:00:15 +0200

Daniel Migault writes:
> <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:
> 
> their life time and that the appropriate use of the key remains across reboots
> - e.g. conditions on counters and nonces remains valid.
> 
> </mglt> 

Looks ok. 

> can't we consider this as a random generator - of a limited lifetime. 

That method is very common piece used when you are making random
number generator. It is for example part of the NIST AES Counter mode
based generator, but to properly make random number generator out of
that need bit more stuff around it. For example you need to make sure
it is rekeyed before the counter rolls over, and of course it is only
as secure as the random secret key you are using to seed it etc.

See NIST SP 800-90A REv 1 [1] CTR_DRBG description for more
information.

[1] https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final
-- 
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Mon, 2 Nov 2020 12:12:03 -0500

Thanks for the response and the reference. The Security Considerations
referred to 4086, but I thought that it would be useful to add the
reference from the nist. I have added the following sentence.

"""
In addition [SP-800-90A-Rev-1] provides appropriated guidances to build
random generators based on deterministic random functions.
"""
I believe that we do not necessarily need to go into more details that are
related to specific transforms, but I am happy to hear otherwise.

Yours,
Daniel

On Mon, Nov 2, 2020 at 9:00 AM Tero Kivinen <[email-masked]> wrote:

> nonce
> reboots

-- 
Daniel Migault
Ericsson