--- 1/draft-ietf-lwig-minimal-esp-01.txt 2020-11-02 10:14:03.618872668 -0800 +++ 2/draft-ietf-lwig-minimal-esp-02.txt 2020-11-02 10:14:03.654873577 -0800 @@ -1,19 +1,19 @@ Light-Weight Implementation Guidance (lwig) D. Migault Internet-Draft Ericsson Intended status: Informational T. Guggemos -Expires: May 1, 2021 LMU Munich - October 28, 2020 +Expires: May 6, 2021 LMU Munich + November 2, 2020 Minimal ESP - draft-ietf-lwig-minimal-esp-01 + draft-ietf-lwig-minimal-esp-02 Abstract This document describes a minimal implementation of the 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, but instead to enable a limited implementation to interoperate with implementations of RFC 4303 ESP. @@ -34,21 +34,21 @@ 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 May 1, 2021. + This Internet-Draft will expire on May 6, 2021. Copyright Notice Copyright (c) 2020 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 @@ -281,25 +281,25 @@ SN can be encoded over 32 bits or 64 bits - known as Extended Sequence Number (ESN). As per [RFC4303], the support 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 life time 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 primary determined by the security associated - to the key rather than the SN. The security of the key used to - encrypt decreases with each message being sent and a node MUST ensure - the limit is not reached - even though the SN would permit it. In a - constrainted environment, it is likely that the implementation of a - rekey mechanism is preferred over the use of ESN. + to 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. In a constrainted environment, it is likely that the + implementation of a rekey mechanism is preferred over the use of ESN. 5. 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. @@ -485,26 +485,29 @@ 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. + session key is, for example, provisioned, the nodes MUST ensure that + keys are not used beyond their life time and that the appropriated + 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]. + generated, the random generation MUST follow [RFC4086]. In addition + [SP-800-90A-Rev-1] provides appropriated guidances to build random + generators based on deterministic random functions. 11. Acknowledgment The authors would like to thank Daniel Palomares, Scott Fluhrer, Tero Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson for their valuable comments. In particular Scott Fluhrer suggested to include the rekey index in the SPI as well as the use of transform resilient to nonce misuse. 12. References @@ -572,20 +575,26 @@ [I-D.nikander-esp-beet-mode] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 (work in progress), August 2008. [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", RFC 8452, DOI 10.17487/RFC8452, April 2019, . + [SP-800-90A-Rev-1] + Elain, E. and J. Kelsey, "Recommendation for Random Number + Generation Using Deterministic Random Bit Generators", + . + Appendix A. Document Change Log [RFC Editor: This section is to be removed before publication] -00: First version published. -01: Clarified description -02: Clarified description