--- 1/draft-ietf-lwig-minimal-esp-07.txt 2021-11-08 16:13:04.377968431 -0800 +++ 2/draft-ietf-lwig-minimal-esp-08.txt 2021-11-08 16:13:04.397968661 -0800 @@ -1,55 +1,54 @@ Light-Weight Implementation Guidance (lwig) D.M. Migault Internet-Draft Ericsson Intended status: Informational T.G. Guggemos -Expires: 1 April 2022 LMU Munich - 28 September 2021 +Expires: 12 May 2022 LMU Munich + 8 November 2021 - Minimal ESP - draft-ietf-lwig-minimal-esp-07 + Minimal IP Encapsulating Security Payload (ESP) + draft-ietf-lwig-minimal-esp-08 Abstract - This document describes a minimal IP Encapsulation Security Payload - (ESP) defined in RFC 4303. Its purpose is to enable implementation - of ESP with a minimal set of options to remain compatible with ESP as - described in RFC 4303. A minimal version of ESP is not intended to - become a replacement of the RFC 4303 ESP. Instead, a minimal - implementation is expected to be optimized for constrained - environment while remaining interoperable with implementations of RFC - 4303 ESP. In addition, this document also provides some - considerations to implement minimal ESP in a constrained environment - which includes limiting the number of flash writes, handling frequent - wakeup / sleep states, limiting wakeup time, or reducing the use of - random generation. + This document describes the minimal properties IP Encapsulating + Security Payload (ESP) implementation needs to meet to remain + interoperable with the standard RFC4303 ESP. Such a minimal version + of ESP is not intended to become a replacement of the RFC 4303 ESP. + Instead, a minimal implementation is expected to be optimized for + constrained environment while remaining interoperable with + implementations of RFC 4303 ESP. In addition, this document also + provides some considerations to implement minimal ESP in a + constrained environment which includes limiting the number of flash + writes, handling frequent wakeup / sleep states, limiting wakeup + time, or reducing the use of random generation. This document does not update or modify RFC 4303, but provides a compact description of how to implement the minimal version of the protocol. RFC 4303 remains the authoritative description. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 1 April 2022. + This Internet-Draft will expire on 12 May 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -141,25 +140,25 @@ According to the [RFC4303], the SPI is a mandatory 32 bits field and is not allowed to be removed. The SPI has a local significance to index the Security Association (SA). From [RFC4301] section 4.1, nodes supporting only unicast communications can index their SA only using the SPI. On the other hand, nodes supporting multicast communications must also use the IP addresses and thus SA lookup needs to be performed using the longest match. - For nodes supporting only unicast communications, it is recommended - to index SA with the SPI only. The index may be based on the full 32 - bits of SPI or a subset of these bits. The node may require a - combination of the SPI as well as other parameters (like the IP - address) to index the SA. + For nodes supporting only unicast communications, this document + recommends to index SA with the SPI only. The index may be based on + the full 32 bits of SPI or a subset of these bits. The node may + require a combination of the SPI as well as other parameters (like + the IP address) to index the SA. Values 0-255 must not be used. As per section 2.1 of [RFC4303], values 1-255 are reserved and 0 is only allowed to be used internally and it must not be sent on the wire. [RFC4303] does not require the SPI to be randomly generated over 32 bits. However, this is the recommended way to generate SPIs as it provides some privacy benefits and avoids, for example, correlation between ESP communications. To randomly generate a 32 bit SPI, the node generates a random 32 bit valueand checks it does not fall in @@ -213,26 +212,27 @@ case the SPI would provide some information related to the application of the user. In addition, the device or application may be associated with some vulnerabilities, in which case specific SPI values may be used by an attacker to discover vulnerabilities. While the use of randomly generated SPIs may reduce the leakage or privacy of security related information by ESP itself, these information may also be leaked otherwise. As a result, a privacy analysis should consider at least the type of information as well the traffic pattern before determining non random SPI can be used. - Typically, temperature sensors, wind sensors, used outdoors do not - leak privacy sensitive information and mosty of its traffic is + Typically, temperature sensors, wind sensors, used outdoors may not + leak privacy sensitive information and most of its traffic is expected to be outbound traffic. When used indoors, a sensor that reports every minute an encrypted status of the door (closed or - opened) leaks truly little privacy sensitive information outside the - local network. + opened) may leak truly little privacy sensitive information outside + the local network. In both cases, if the state of the sensor doesn't + leak privacy info, a randomized SPI is not necessary. 3. Sequence Number(SN) (32 bit) According to [RFC4303], the Sequence Number (SN) is a mandatory 32 bits field in the packet. The SN is set by the sender so the receiver can implement anti-replay protection. The SN is derived from any strictly increasing function that guarantees: if packet B is sent after packet A, then SN of packet B is strictly greater than the SN of packet A. @@ -259,76 +259,77 @@ flash memory - that can be restored across sleeps. Storing information associated with the SA such as SN requires some read and writing operation on a stable storage after each packet is sent as opposed to SPI or keys that are only written at the creation of the SA. Such operations are likely to wear out the flash, and slow down the system greatly, as writing to flash is not as fast as reading. 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. Using time for SN would guarantee a strictly increasing function and avoid storing any - additional values or context related to the SN. When the use of a - clock is considered, one should take care that packets associated - with a given SA are not sent with the same time value. Note however - that standard receivers are generally configured with incrementing - counters and, if not appropriately configured, the use of a - significantly larger SN may result in the packet out of the - receiver's windows and that packet being discarded. + additional values or context related to the SN. Of course, one + should only consider use of a clock to generate SNs if the + application will inherently ensure that no two packets with a given + SA are sent with the same time value. Note however that standard + receivers are generally configured with incrementing counters and, if + not appropriately configured, the use of a significantly larger SN + difference may result in the packet out of the receiver's windows and + that packet being discarded. - For inbound traffic, it is recommended that any receiver provides - anti-replay protection, and the size of the window depends on the - ability of the network to deliver packets out of order. As a result, - in an environment where out of order packets is not possible the - window size can be set to one. However, while recommended, there are - no requirements to implement an anti-replay protection mechanism + For inbound traffic, this document recommends that any receiver + provides anti-replay protection, and the size of the window depends + on the ability of the network to deliver packets out of order. As a + result, in an environment where out of order packets is not possible + the window size can be set to one. However, while recommended, there + are no requirements to implement an anti-replay protection mechanism implemented by IPsec. Similarly to the SN the implementation of anti replay protection may require the device to write the received SN for every packet, which may in some cases come with the same drawbacks as those exposed for SN. As a result, some implementations may drop a non required anti replay protection especially when the necessary resource involved overcomes the benefit of the mechanism. These resources need also to balance that absence of anti-replay mechanism, may lead to unnecessary integrity check operations that might be significantly more expensive as well. A typical example might consider an IoT device such as a temperature sensor that is sending a temperature every 60 seconds, and that receives an acknowledgment from the receiver. In such cases, the ability to spoof and replay an - acknowledgement is of limited interest and may not justify the + acknowledgement is of limited interest and might not justify the implementation of an anti replay mechanism. Receiving peers may also - implement their own anti-replay mechanism. Typically, when the - sending peer is using SN based on time, anti-replay may be - implemented by discarding any packets that present a SN whose value - is too much in the past. Note that such mechanisms may consider - clock drifting in various ways in addition to acceptable delay - induced by the network to avoid the anti replay windows rejecting - legitimate packets. When a packet is received at a regular time - interval, some variant of time based mechanisms may not even use the - value of the SN, but instead only consider the receiving time of the - packet. + use ESP anti-replay mechanism adapted to a specific application. + Typically, when the sending peer is using SN based on time, anti- + replay may be implemented by discarding any packets that present a SN + whose value is too much in the past. Note that such mechanisms may + consider clock drifting in various ways in addition to acceptable + delay induced by the network to avoid the anti replay windows + rejecting legitimate packets. When a packet is received at a regular + time interval, some variant of time based mechanisms may not even use + the value of the SN, but instead only consider the receiving time of + the packet. SN can be encoded over 32 bits or 64 bits - known as Extended Sequence Number (ESN). As per [RFC4303], the support of ESN is not mandatory. The determination of the use of ESN is based on the largest possible value a SN can take over a session. When SN is incremented for each packet, the number of packets sent over the lifetime of a session may be considered. However, when the SN is incremented differently - such as when time is used - the maximum value SN needs to be considered instead. Note that the limit of messages being sent is primarily determined by the security associated with the key rather than the SN. The security of all data protected under a given key decreases slightly with each message and a node must ensure the limit is not reached - even though the SN would permit it. Estimation of the maximum number of packets to be sent by a node is always challenging and as such should be considered cautiously as nodes could be online for much more time than expected. - Even for constrained devices, it is recommended to implement some - rekey mechanisms (see Section 9). + Even for constrained devices, this document recommends to implement + some rekey mechanisms (see Section 9). 4. Padding The purpose of padding is to respect the 32 bit alignment of ESP or block size expected by an encryption transform - such as AES-CBC for example. ESP must have at least one padding byte Pad Length that indicates the padding length. ESP padding bytes are generated by a succession of unsigned bytes starting with 1, 2, 3 with the last byte set to Pad Length, where Pad Length designates the length of the padding bytes. @@ -342,22 +343,22 @@ would typically be the case when the Data Payload is of fix size. ESP [RFC4303] also provides Traffic Flow Confidentiality (TFC) as a way to perform padding to hide traffic characteristics, which differs from respecting a 32 bit alignment. TFC is not mandatory and must be negotiated with the SA management protocol. TFC has not yet being widely adopted for standard ESP traffic. One possible reason is that it requires to shape the traffic according to one traffic pattern that needs to be maintained. This is likely to require extra processing as well as providing a "well recognized" traffic shape - which could end up being counterproductive. As such, it is NOT - recommended that minimal ESP implementation supports TFC. + which could end up being counterproductive. As such, this document + does not recommend that minimal ESP implementation supports TFC. As a result, TFC cannot be enabled with minimal ESP, and communication protection that were relying on TFC will be more sensitive to traffic shaping. This could expose the application as well as the devices used to a passive monitoring attacker. Such information could be used by the attacker in case a vulnerability is disclosed on the specific device. In addition, some application use - such as health applications - may also reveal important privacy oriented information. @@ -384,21 +385,21 @@ in the packet. Next header specifies the data contained in the payload as well as dummy packet, i.e. packets with the Next Header with a value 59 meaning "no next header". In addition, the Next Header may also carry an indication on how to process the packet [I-D.nikander-esp-beet-mode]. The ability to generate and receive dummy packets is required by [RFC4303]. For interoperability, a minimal ESP implementation must discard dummy packets without indicating an error. Note that such recommendation only applies for nodes receiving packets, and that - nodes designed to only send data may not implement this capability. + nodes designed to only send data might not implement this capability. As the generation of dummy packets is subject to local management and based on a per-SA basis, a minimal ESP implementation may not generate such dummy packet. More especially, in constrained environment sending dummy packets may have too much impact on the device lifetime, and so may be avoided. On the other hand, constrained nodes may be dedicated to specific applications, in which case, traffic pattern may expose the application or the type of node. For these nodes, not sending dummy packet may have some privacy implication that needs to be measured. However, for the same reasons @@ -447,24 +448,24 @@ outdated ciphers). ESP can be used to authenticate only or to encrypt the communication. In the latter case, authenticated encryption must always be considered [RFC8221]. 2. Resilience to nonce re-use: Some transforms -including AES-GCM - are very sensitive to nonce collision with a given key. While the generation of the nonce may prevent such collision during a session, the mechanisms are unlikely to provide such protection across reboot. This causes an issue for devices that are configured with a key. When the key is likely to be re-used - across reboots, it is recommended to consider algorithms that are - nonce misuse resistant such as, for example, AES-SIV [RFC5297], - AES-GCM-SIV [RFC8452] or Deoxys-II [DeoxysII]. Note however that - currently none of them has yet been defined for ESP. + across reboots, this document recommends to consider algorithms + that are nonce misuse resistant such as, for example, AES-SIV + [RFC5297], AES-GCM-SIV [RFC8452] or Deoxys-II [DeoxysII]. Note + however that currently none of them has yet been defined for ESP. 3. Interoperability: Interoperability considers the encryption algorithm transforms shared with the other nodes. Note that it is not because an encryption algorithm transform is widely deployed that it is secured. As a result, security should not be weakened for interoperability. [RFC8221] and successors consider the life cycle of encryption algorithm transforms sufficiently long to provide interoperability. Constrained devices may have limited interoperability requirements which makes possible to reduces the number of encryption algorithm transforms to @@ -511,46 +512,46 @@ document provided security recommendations and guidance over the implementation choices for each field. The security of a communication provided by ESP is closely related to the security associated with the management of that key. This usually includes mechanisms to prevent a nonce from repeating, 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 with key management - protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 - [RFC7815]. Such mechanisms are responsible for negotiating fresh - session keys as well as prevent a session key being use beyond its - lifetime. 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 lifetime and that the appropriate use of the - key remains across reboots - e.g. conditions on counters and nonces - remains valid. + This document recommends to use ESP in conjunction with key + management protocols such as for example IKEv2 [RFC7296] or minimal + IKEv2 [RFC7815]. Such mechanisms are responsible for negotiating + fresh session keys as well as prevent a session key being use beyond + its lifetime. 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 lifetime and that the appropriate use + of the key remains across reboots - e.g. conditions on counters and + nonces remains valid. 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. 10. Acknowledgment The authors would like to thank Daniel Palomares, Scott Fluhrer, Tero - Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson, Thomas Peyrin - and Eric Thormarker for their valuable comments. In particular Scott - Fluhrer suggested to include the rekey index in the SPI. Tero - Kivinen provided also multiple clarifications and examples of - deployment ESP within constrained devices with their associated - optimizations. Thomas Peyrin Eric Thormarker and Scott Fluhrer - suggested and clarified the use of transform resilient to nonce - misuse. + Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson, Thomas Peyrin, + Eric Thormarker, Nancy Cam-Winget and Bob Briscoe for their valuable + comments. In particular Scott Fluhrer suggested to include the rekey + index in the SPI. Tero Kivinen provided also multiple clarifications + and examples of deployment ESP within constrained devices with their + associated optimizations. Thomas Peyrin Eric Thormarker and Scott + Fluhrer suggested and clarified the use of transform resilient to + nonce misuse. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, .