Re: [Lwip] [IPsec] draft-ietf-lwig-minimal-esp shepherd writeup

[Mohit Sethi M <[e-mail]>]

Hi Paul,

Adding Ben (IPsecME AD) and Erik (LWIG AD) to the CC list for an early heads up.

Thanks for reviewing the document. I'll let the authors provide answers to your review.

On the procedural side of things: this document is within the LWIG charter (https://datatracker.ietf.org/wg/lwig/charter/) and follows the path taken by Minimal IKEv2 which was also completed in LWIG as RFC 7815 (https://datatracker.ietf.org/doc/rfc7815/).

During the call for adoption, there was a general consensus to proceed in LWIG while keeping close contacts with IPsecME (as well as an agreement to issue a joint last call). Tero (https://mailarchive.ietf.org/arch/msg/lwip/Shf2oUKvtIsb0uzY2zRwuBurm58/), Valery (https://mailarchive.ietf.org/arch/msg/lwip/p1i4hZBjn7PD3ksS9kh8C0ouUOU/) and Scott (https://mailarchive.ietf.org/arch/msg/lwip/dF3eZXG8GTV-o7aH4BnFk2zlR6c/) for example provided reviews of the draft.

I think your comments during the adoption (https://mailarchive.ietf.org/arch/msg/lwip/xDcICiuALZ2ExF3qwRCnhCQC3A0/) did not argue moving this draft to IPsecME (unless I missed something):

If the document is defining a minimum/battery optimized ESP
configuartion, I have no problems with it and I will review further
text and welcome adoption. If it makes changes to the ESP protocol,
then I think there should be more discussion before adoption.

Paul

That being said, I am not fundamentally opposed to moving this document to IPsecME. However, it is important to consider that the document has already had a relatively long lifecycle in LWIG.

--Mohit

On 3/22/21 6:12 AM, Paul Wouters wrote:
On Sun, 21 Mar 2021, Daniel Migault wrote:

(replying to some issues here, but also added a full review of the document)

Side note: I am bit confused why this document would not be a document
from the IPsecME WG ? I know we talked about this before? Did we decide
against adoption at IPsecME ? Can the authors, WG chairs of IPsecME or
the responsible AD shed some light on the history here?

In general, this draft is very "wordy" because it is trying to steer
itself around a lot of problems, without making firm decisions. But
the point of an RFC is that it should make clear decisions that
implementers can adopt clearly. As such, I'm not in favour of this
draft. I believe I stated this before?

[1] https://protect2.fireeye.com/v1/url?k=267ff37b-79e4ca56-267fb3e0-8692dc8284cb-4b11e1d62003bf58&q=1&e=de278ec7-abe4-4a5c-bad8-76ad8f57cf87&u=https%3A%2F%2Fgithub.com%2Fmglt%2Fdraft-mglt-lwig-minimal-esp%2Fcommit%2F47f1351b1928ba687af18e75e253e98720448e8e
On Sat, Mar 20, 2021 at 5:12 AM Mohit Sethi M <mohit.m.sethi=[e-mail]><mailto:mohit.m.sethi=[e-mail]> wrote:
      I am now preparing the shepherd writeup for draft-ietf-lwig-minimal-esp.
      I wanted to clarify and double check a few things:

      - If the SPI is not random and is chosen by some application specific
      method -> it can reveal the application using ESP.

<mglt>
It is correct that the use of non random SPI may have some privacy impacts and one of these impacts is that in some cases, a SPI may be used to track an application. Note that our intention was to make it
clear that when SPI are non randomly generated, there are some privacy implications to consider as well as that randomly generated SPI is preferred.

At the time I also mentioned one attack against IKE that was twarted by
having 4 random bytes as SPI. It remains dangerous to change this
property of ESP, and I recommended to not do that.

https://access.redhat.com/blogs/product-security/posts/sloth

But it seems that although my comments caused the draft to be modified,
it still allows non-random SPIs:

   However, for some constrained nodes, generating and handling 32 bit
   random SPI may consume too much resource, in which case SPI can be
   generated using predictable functions or end up in a using a subset
   of the possible values for SPI.  In fact, the SPI does not
   necessarily need to be randomly generated.  A node provisioned with
   keys by a third party - e.g. that does not generate them - and that
   uses a transform that does not needs random data may not have such
   random generators.  However, nonrandom SPI and restricting their
   possible values MAY lead to privacy and security concerns.  As a
   result, this alternative should be considered for devices that would
   be strongly impacted by the generation of a random SPI and after
   understanding the privacy and security impact of generating nonrandom
   SPI.

So I feel I raised a security issue, and the text just copied my concern
but still basically states implementations MAY do this. I believe this
is wrong.

Note that the draft defined one (common way) to generate the SPI value that is using a random generator to generate this SPI value. All other means fall into the category of using deterministic functions.
This does not necessarily mean that a fix of predefined SPI will necessarily be used. This includes for example the fact that only 2**16 or 2**24 values may be candidates. The case where one device has a
very limited number of SPI is quite extreme. In any case, it should be estimated how much the SPI leaks more information than the IP destination and the use of IPsec as well as the pattern associated with
the traffic.

I'm not concerned about privacy. As you stated, it is usually pretty
clear what an IoT device is based on where it connects to. I am far
more concerned about security.

However, for some constrained nodes, generating and handling 32 bit random SPI may
consume too much resource, in which case SPI can be generated using
predictable functions or end up in a using a subset of the possible values for SPI.

If such a device cannot generate 4 random bytes, how is it performing a
DiffieHellman key exchange? Or is it presumed that IKE is done
elsewhere? In which case "elsewhere" can generate 4 random bytes.

What about IVs ? If you cannot generate 4 bytes of random, how it is
going to generate the IVs required for ESP?

In fact, the SPI does not necessarily need to be randomly generated.

Yes it is does, see the above link on an attack against IKE where the
randomized SPI made offline attacks impossible and online attacks
impractical.

A node provisioned with keys by a third party - e.g. that does not generate them - and that uses a transform that does not need random data may not have such random generators.

There is a strong move to AEADs, and it would be foolish to limit IoT to
things like AES-CBC because of the IV generation.

      - When sequence numbers are time -> won't it reveal the time at which
      the packet was sent.

<mglt>
First the use of time is primarily driven to have a always increasing function, more than the value of the time itself. This could be used with a clock that is 2 years back in the past or in the future. It
is correct that a few packet analysis may reveal how synchronized the clock of the device is.
Regarding the time the packet has been sent, it seems to me this is relatively close to the time the  time is captured, but maybe I am missing how this could be used or any specific cases where delay
tolerant networks are involved. So I am inclined to say that yes this may leak some information, but this information may already be leaked.

</mglt>

The secion on Sequence Numbers concerns me too, and for the same reasons
as above. If you cannot keep a sequence number as state, you cannot do
any AEAD encryption. I believe it is a bad idea to still write
specifications today that require non-AEAD algorithms. Once you can do
it for AEAD, then you can do it for SN too (and using the other draft
that specified re-using the SN for one of these for other saves you
those bytes once).


      - Are we comfortable with the recommendation: 'A node MAY drop
      anti-replay protection provided by IPsec, and instead implement its own
      internal mechanism.'? What might this internal mechanism look like?

Again, I do not think that we should write RFCs where to disable
security meassures because the device is too constrained. If that is
the case, perhaps IPsec is not the protocol that should be used? Yes,
we can use IPsec without replay protection, but it is unwise to do so.
Handwaving it to be the implementors or application's problem is a bit
dangerous (though not as dangerous as the SPI case above)


Padding I am less concerned about. Often it is not needed, and TFC is
indeed not used a lot - mostly I think because it really only makes
sense to use TFC based on MTU size, but that in itself will cause
more MTU related issues. And an IoT device is likely to send a fixed
format packet anyway with minimal or no change in packet length, in
which case all packets will be the same length. It could create real
security concerns though, if one could deduce a password length or
something based on the type of IoT device and its packet length.


    For interoperability, it is RECOMMENDED a minimal ESP
    implementation discards dummy packets.

I'm not sure what this means. What else would one do with a dummy
packet? Regardless, I don't know of implementations that currently
support sending dummy packets.

I'm a little confused what Section 7 is saying? What does the
implementer need to take in from reading this ?


    In the latter case, authenticated encryption must always be considered [RFC8221].

I'm unsure what this means? Do you mean AEAD? Or are you refering to the
obsolete encryption without _any_ authentication (eg ESP without
authentication _and_ without AH ) ? Regardless of that "must always be
considered" is basically saying nothing. It is not strong enough.
Compare this to:

https://datatracker.ietf.org/doc/html/rfc8221#section-4

where it clearly states MUST NOT. So your text is is basically negating
that MUST NOT to "consider".

    When the key is likely to be re-used
       across reboots, it is RECOMMENDED to consider transforms that are
       nonce misuse resistant such as AES-GCM-SIV

But there is no AES-GCM-SIV IKE or ESP algorithm, so you cannot
recommend that. The only thing you can recommend is AES-CBC, and as I
said before, recommending non-AEAD over AEAD is not something I think
the IETF should do.

I cannot parse this sentence:

    Note that it
    is not because an encryption algorithm transform is widely
    deployed that is secured.


I also see some promotion of AES-CTR, which I'm a little uncomfortable
with.


The security considerations section does not list the issue I've raised
here. For AEAD it states that "mechanisms MUST be in place" to prevent
nonce re-use, but the document doesn't really give guidance. In fact,
if anything it is saying there there is no way to carry state across
reboots for that and that keys might be somehow hardcoded and re-used?
So I would like to ask again, what concrete thing should an implementer
take from this section, eg when it is implementing AES-GCM ?

After lots of talk that generating 4 random bytes for the SPI might be
too hard, the Security Considerations lists:

    When a node generates its key or when random value such as nonces are
    generated, the random generation MUST follow [RFC4086].  In addition
    [SP-800-90A-Rev-1] provides appropriated guidance to build random
    generators based on deterministic random functions.

If you can do that, you can do 4 bytes of random SPI. So these two items
are contradicting each other. Either you can easilly generate random
SPIs and we should keep them at 4 bytes, OR we simply don't have the
resources for RFC4086 and SP-800-90A-Rev-1 based random number
generates. I mean, I can't see them doing a continious self test for
random required by FIPS if you can't even generate 4 bytes of random
SPI.


In conclusion, I think this document is not helpful to implementers. It
is very wordy but lacks clear advise to implementors and while it raises
security issues for those implementers, it does not actually present
solutions for them.

Paul