Paul Wouters writes:
> 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?
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.
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.
> 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. Requiring SPIs to be random
would be a change from RFC4303, and as such cannot be done in this
document.
For example RFC4301 defines SPI as follows in its Appendix A:
Glossary:
----------------------------------------------------------------------
Security Parameters Index (SPI)
An arbitrary 32-bit value that is used by a receiver to identify
the SA to which an incoming packet should be bound. For a unicast
SA, the SPI can be used by itself to specify an SA, or it may be
used in conjunction with the IPsec protocol type. Additional IP
address information is used to identify multicast SAs. The SPI is
carried in AH and ESP protocols to enable the receiving system to
select the SA under which a received packet will be processed. An
SPI has only local significance, as defined by the creator of the
SA (usually the receiver of the packet carrying the SPI); thus an
SPI is generally viewed as an opaque bit string. However, the
creator of an SA may choose to interpret the bits in an SPI to
facilitate local processing.
----------------------------------------------------------------------
>From the last sentence it is clear that SPI can also be non-random.
You can for example take last 8 bits of the SPI and use that as CPU
identifier, and use next 16-bits before that as index to the SPI table
on that CPU specific SPI table, and use 0xff as first 8-bits just so
you never end up having any reserved numbers for your SPI, i.e., have
SPI as 0xffiiiicc, where iiii is index and cc is cpu id.
> 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.
But wasn't that attack you referenced, talking about IKE SPIs, not ESP
SPIs? At least that is what I remember about that attack...
Also even IKE SPIs are not required to be random, they are just
required to be unique and non-zero.
> 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.
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,
> > 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.
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.
> 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
writing to flash is not that fast operation than reading from there.
Note, that lots of these IoT devices wake up, do something, send few
packets, and then go back to sleep. They do have separete hardware
that allows them to wake up after certain timeout, and most likely
also timers that start running when the device was booted up, so they
might have concept of time with certain granularity. They might NOT
have real time clocks or any information how their internal clock
relates to real world clock, and their internal clocks/timers might
not be very accurate, but they should be enough to know that each time
they wake up their time is greater than what it was last time they
woke up.
> 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)
If you want to change this we need to revise RFC4303 and RFC4301.
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.
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.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
