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

[Daniel Migault <[e-mail]>]

Hi,

To complement my previous response, I have added some text provided by Tero
to clarify the generation of SN from the time. We also added some
explanation around anti replay as well as some more context on the various
constraints different devices may have. We also add some clarification
about what dummy packet are as it seemed the reference to RFC4301 and
section was not sufficient.
On the other hand, I do not believe that is necessary to duplicate the
discussion around the choice of a specific transform and this discussion
should happen in the ESP cryptographic recommendations RFC8221. This also
avoids the document to be updated as crypto evolves and new transforms are
introduced.

The current version is available here:
https://github.com/mglt/draft-mglt-lwig-minimal-esp/blob/master/draft-ietf-lwig-minimal-esp.xml

Please find my response inline.

Yours,
Daniel



On Mon, Mar 22, 2021 at 12:45 PM Paul Wouters <[e-mail]> wrote:

> On Mon, 22 Mar 2021, Tero Kivinen wrote:
>
> >> 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?
> >
> > This draft does not change anything in the ESP, it only gives
> > guidelines to the lightweight implementations so they can more easily
> > understand what kind of optimizations are allowed by standard ESP and
> > what benefits or concerns there might be from selecting them.
>
> I find the guidelines it gives unclear. This email has helped a lot and
> I would really like to see some of this text included in the draft.
>
> > Because it does not change ESP, it is not really IPsecME WG job. It is
> > similar than RFC7815 Minimal IKEv2 Initiator Implementation document,
> > which was also published from the LWIG WG and not from the IPsecME WG.
>
> Thanks for the process explanation. I'm okay continuing it this way.
>
> >> But it seems that although my comments caused the draft to be modified,
> >> it still allows non-random SPIs:
> >
> > This document cannot mandate that SPIs need to be random, as no such
> > requirement is in the standard ESP RFC.
>
> Interesting, I did not realise that. The draft could be clarified to
> simply state like, something like:
>
>         RFC4303 states tat SPI's must be unique, but do not require to
>         be random. Most implementations do use random SPIs but this
>         might not be possible for constrained devices. These devices
>         MAY use non-random SPIs.
>
> > But wasn't that attack you referenced, talking about IKE SPIs, not ESP
> > SPIs? At least that is what I remember about that attack...
>
> Yes, that is correct.
>
> > Also even IKE SPIs are not required to be random, they are just
> > required to be unique and non-zero.
>
> Perhaps we should update IKEv2 to SHOULD make them random :)
>
> >> 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.
> >
> > I do not think SPI issue is about generating it, but using it for each
> > incoming packet. If device has only support for 4 incoming SPIs, it
> > might just create SPIs using format 0x8000000x, where x is the index
> > in its SAD. Then getting address of SAD structure in memory could
> > simply be (SPI << (sad_table_shift)) + sad_table_start_address after
> > checking that (spi & 0xfffffffc) == 0x80000000.
>
> Again the draft should be making this distinction clear. To me it seems
> to suggest that creating them randmonly was the problem being addressed.
>
> > Generation of the SPI is single operation, and as such not an issue.
> > Mapping SPI -> SAD entry must be done for every incoming packet, and
> > saving cycles from there might make difference.
> >
> >> What about IVs ? If you cannot generate 4 bytes of random, how it is
> >> going to generate the IVs required for ESP?
> >
> > Implicit Initialization Vector (IV) for Counter-Based Ciphers in
> > Encapsulating Security Payload (ESP), RFC 8750,
>
> That is only for the IV of AEAD algorithms. But the draft wiggles between
> discourages these because if you re-use the key along reboots without
> keeping
> state, you would re-use the same IV (counter). Later on in the document,
> and along with your explanation in this email, I understand that the
> time based counter addresses this. I think it should be made much more
> explicitly clear so that implementers know this.
>
>
> For AES-CBC, RFC 3602 states:
> https://tools.ietf.org/html/rfc3602#section-3
>
>         The IV field MUST be the same size as the block size of the cipher
>         algorithm being used.  The IV MUST be chosen at random, and MUST be
>         unpredictable.
>
> So the draft basically states that for systems not able to generate a
> random bytes, that it cannot use AES-CBC. It should state this
> explictly.
>
> > IKE SPI or ESP SPI? My understanding those attacks were against IKE,
> > not against ESP.
> >
> > And if what you are saying is true, then we as an IPsecME needs to
> > start making modification to the ESP to actually require the SPI to be
> > random. Currently it does not need to be random, just unique from the
> > local point of view.
>
> Based on the attack, this would only be needed for IKE, not ESP. But for
> implementations this draft targets, that would be a similar
> insurmountable problem? Again, it would be useful to explain why pure
> random is harder to do then using something time based.
>
> >> 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).
> >
> > You can use AEAD encryption with sequence numbers generated by time
> > without any problems. I would expect most of the IoT devices will use
> > AEAD ciphers, as for example IEEE Std 802.15.4 is only defined to
> > support AEAD ciphers, and the only one currently defined there is
> > AES-CCM, and that AEAD AES-CCM is used with timebased nonces when used
> > with TSCH currently.
> >
> > The problem with regular sequence numbers is that you need to store
> > them to stable storage every time you go sleep. Storing the SA
> > information (keys, SPIs etc) to the flash once after the creation of
> > the SA can be done, as that is just one flash write per SA creation.
> > Syncing sequence number to flash after every packet would quickly wear
> > out the flash, and most likely also slow down the system greatly, as
>
> That's a great explanation of how AEAD can work and the difference
> between storing sequence numbers and storing crypto keys. It should be
> in the draft too.
>
> > Replay protection has always been optional for the receiver. There are
> > lots of ways to do things in a way where you do NOT need replay
> > protection on the ESP layer.
> >
> > The problem with replay protection is again that it needs to be stored
> > across sleeps, i.e., written to the flash memory.
>
> Again, please add this to the draft.
>
> > If the IoT device you are talking about is for example temperature
> > sensor and the protocol is such that sensor wakes up every 60 seconds,
> > sends sensor measurement over ESP, and waits for ACK back from the
> > controller, and after receiving the ACK it goes back to sleep, there
> > is no need to have replay protection on the sensor end. Yes, attacker
> > who can block the connection between the sensor and controller, can
> > replay ACKs and cause the sensor to be happy and not notice that it
> > has lost connection to the controller, but on the other hand even if
> > the sensor would notice that it has lost the connection to controller,
> > there is nothing it can do, as there is no way of indicating that
> > information other than over the radio and attacker is already blocking
> > that. Temperature sensors usually do not have displays or keyboards,
> > and even when there might be LEDs on the board, they do not help much
> > when the sensor is inside the building wall.
>
> Again, great addition for anyone reading the draft why it is okay.
>
> Reading back now, I think with some clarifications added, I am okay
> with the document. I think the list of clarifications we now have is:
>
> - clarifying ESP SPI's do not need to be random, with reference to 4304
>    and explain why random ones take more resources and fixed ones might
>    be used.
>

<mglt>
The text seems as it is sufficient to address your concern:
In fact, the SPI does not necessarily need to be randomly generated.

When a constrained node limits the number of possible SPIs this limit
should both consider the number of
inbound SAs - possibly per IP addresses - as well as the ability for the
node to rekey.
SPI can typically be used to proceed to clean key update and the SPI value
may be used to indicate which key
is being used. This can typically be implemented by a SPI being encoded
with the Security Association Databas
e (SAD) entry on a subset of bytes (for example 3 bytes), while the
remaining byte is left to indicate the re
key index.
</mglt>

> - clarify why counter as entire IV is okay (because AEAD) and why
>    storing an absolute counter on  flash is bad, and timing can be used
>    instead.
>
<mglt>
The text already mentions RFC8750
</mglt>

> - Clarify why sequence numbers cannot be sequential - flash writes are
>    bad.
>
<mglt>
Text proposed by Tero has been included.
</mglt>

> - A clear section on why AES-CBC/3DES-CBC cannot be used due to IV
>    randomness limitations
>
<mglt>
The text delegates the crypto recommendations to 8221 which mentions 3DES
has should not and mentions AES_CBC to be replaced. I do not think that the
discussion should be duplicated here. In addition the text mentions the
following recommendations:
 - Use of counter-based ciphers without fixed block length (e.g. AES-CTR,
or ChaCha20-Poly1305).
 - Use of ciphers recommended for IoT *[*RFC8221].
</mglt>

> - clearly recommending an AEAD like AES-CCM or AES-GCM. Consider using
>    their IV-less names from RFC 8750.
>
<mglt>
The text mentions as a second recommendation:
- Use of ciphers with capability of using implicit IVs *[*RFC8750].
</mglt>

> - Remove reference to AES-GCM-SIV which does not exist for ESP, or
>    clarify "once/if available for ESP".
>
<mglt>
ESP does not define transform these are defined by IKE. AES-GCM-SIV is the
algorithm not the transform. See my response in my previous email.
</mglt>

> - call "ChaCha20-Poly1305" by its name CHACHA20_POLY1305 (and maybe also
>    by its RFC 8750 name)
>
<mglt>
The ChaCha20-Poly1305 is mentioned for its cryptography properties not as a
transform. These remain independent of the multiple associated transform
using it. Again the choice of the specific transform is delegated to
RFC8221.
</mglt>

> - clarifying section 6 that this is not about the Next Header (being
>    removed) but just about not supporting dummy packets. Probably change
>    the title of the section too.
>
 <mglt>
I understand the problem was a mis interpretation of the dummy packet which
has been clarified with the following text:
"""
 i.e. packets with the Next Header with a value 59 meaning "no next
header".
"""
</mglt>

> - change "cryptographic suites" and "crypto-suites" to "cryptographic
>    algorithms" to avoid TLS confusion
>
<mglt>
I think IKEv2 uses suites or transform.
</mglt>

> - update the introduction to introduce the constrains (flash writes,
>    wake/up sleep vs reboot, getrandom limitations)
>
<mglt>
The text has been updated with :
 As a result, constraint devices are likely to have their own
implementation of ESP optimized and adapted to t
heir specificities such as limiting the number of flash writes (for each
packets or across wake time), handli
ng frequence wake/up sleep while limiting wake time, or reducing the use of
random generation.
</mglt>

>  - figure out what to do with the FIPS reference on randomness (because
>    I don't think with continuous self test, it can be fully FIPS
>    compliant?)
>
<mglt>
The reference has been kept as suggested by Scott.
</mglt>

> - Clarify the list in section 8. Is this ordered from most important
>    to least important? I think so but it does not state this.
>
<mglt>
I find it difficult to define a universal order.
</mglt>

> - Remove reference to I-D.nikander-esp-beet-mode, with the text "not
>    standarized yet". This draft has been abandoned in 13 years ago.
>
> <mglt>
I think it is useful to keep the text mentioning that in some case NH is
used otherwise but we do not have to bother. While not standardized, it is
implemented and used. I agree though it is not essential, but I do not see
it as hurting.
</mglt>

> I'm willing to help with text if the authors want, but I think if I did
> that, the diff would be quite large as I would be clarifying things be
> being more epxlicit and use fewer words. So it might be better if the
> goal is to keep the changes to a minimum for the draft authors to make
> the changes.
>
> <mglt>
We want to keep the changes minimal also to avoid overwriting text that has
been agreed before.
</mglt>

> Paul
>


-- 
Daniel Migault
Ericsson