diff --git a/eesp-ikev2.org b/eesp-ikev2.org index fe316db..683708e 100644 --- a/eesp-ikev2.org +++ b/eesp-ikev2.org @@ -51,8 +51,9 @@ prior to decryption. EESP also enables the establishment of Sub SAs with independent keys and sequence number spaces. Additionally, it supports the use of 64-bit sequence numbers transmitted in each packet or the omission of sequence numbers when the Replay Protection -service is not needed. EESP packets carry a version number, enabling -easier support for future extensions. +service is not needed or cannot be achieved (e.g. in some multicast +scenarios). EESP packets carry a version number, enabling easier +support for future extensions. This document specifies the negotiation of EESP Security Associations (SAs) within the Internet Key Exchange Protocol @@ -234,15 +235,15 @@ Use of Sub SAs is optional in EESP and can be negotiated using IKEv2. ** EESP Sequence Numbers -Unlike ESP, EESPv0 header allows to transmit 64-bit sequence numbers. -In addition, the Sequence Number field in the EESPv0 header is -optional and can be omitted from the packet if replay protection -service is not needed. Note that while possible, disabling the -replay protection service is generally NOT RECOMMENDED and should -only be done if the upper level protocol provides this service. See -[[Security Considerations]] for details. +Unlike ESP, the EESPv0 header transmits 64-bit sequence numbers if +replay protection is used. In addition, the Sequence Number field in +the EESPv0 header is optional and can be omitted from the packet if +replay protection is not needed. Note that while possible, disabling +replay protection is generally NOT RECOMMENDED and should only +be done in case of multicast scenarios or if the upper level protocol +provides this service. See [[Security Considerations]] for details. -# [VS] I believe this is covered below in the discssion about +# [VS] I believe this is covered below in the discussion about # [VS] restrictions on negotiated parameters # ** Explicit Initialization Vector @@ -343,21 +344,18 @@ The type of the Sub SA Key Derivation Function transform is . *** New Transform IDs for Sequence Numbers Transform Type This document defines two new Transform IDs for the Sequence Numbers -transform type: ~64-bit Sequential Numbers~ () and ~None~ (). +transform type: ~64-bit Sequential Numbers~ () and ~None~ (). -To enable presence of sequence numbers in the EESP header the -initiator MUST propose SN = (64-bit Sequential Numbers) in the -Proposal Substructure inside the Security Association (SA) payload. -When the responder selects 64-bit Sequential Numbers, the Sequence Number -field is included into the EESP header, that allows peers to -achieve replay protection. - -# NOTE STK: I'd say MUST above as we want to negotiate Anti-Replay -# service and not just the presense of the seq nr field. +To enable the presence of sequence numbers in the EESP header and +enabling replay protection, the initiator MUST propose SN = (64-bit +Sequential Numbers) in the Proposal Substructure inside the Security +Association (SA) payload. When the responder selects 64-bit Sequential +Numbers, the Sequence Number field MUST be included into the EESP +header and peers MUST perform replay protection. To disable sequence numbering, and thus replay protection based on -sequence numbers, the initiator MUST propose SN=None (). -When the responder selects None, Sequence Number field is omitted +sequence numbers, the initiator MUST propose SN=None (). +When the responder selects None, the Sequence Number field is omitted from the EESP header. ** Transforms Consistency @@ -399,15 +397,15 @@ Sequence Numbers transform type (32-bit Sequential Numbers and Partially Transmitted 64-bit Sequential Numbers) are unspecified for EESPv0 and MUST NOT be used in EESPv0 proposals. -Implemenattions MUST ignore transforms containing invalid +Implementations MUST ignore transforms containing invalid values for the current proposal (as if they are unrecognized, in accordance with Section 3.3.6 of [[RFC7296]]). -The use of the None Transform ID for the SN transform +The use of the ~None~ Transform ID for the SN transform if further limited by the ENCR transform. In particular, if the selected ENCR transform defines use of implicit IV -(as transforms defined in [[RFC8750]]), then the value None MUST NOT -be selected for the SN transform. +(as transforms defined in [[RFC8750]]), then the value ~None~ MUST +NOT be selected for the SN transform. ** Example of SA Payload Negotiating EESP @@ -464,17 +462,6 @@ If this notification is received it MUST be ignored. # procedure as deleting Child SA using IKEv2 INFORMATIONAL exchange as # specified in Section 1.4.1 [[RFC7296]] -# * EESP SA Transforms -# EESP introduces several transform properties that are negotiated -# during the establishment of an EESP SA. These properties MUST be -# identical for the duration of the SA. When the SA is rekeyed, -# the new SA MUST inherit all EESP transform properties negotiated for -# the original EESP SA. -# -# | Type | Description | Used In | Reference | -# |------+---------------------------+---------+-----------------+ -# | TBD6 | EESP Session ID(EESPSID) | (EESP) | [this document] | - ** Announcing Maximum Sub SA ID In the process of establishing the EESP SA, each peer MAY inform the @@ -498,8 +485,8 @@ A new notify status type EESP_MAX_SUB_SA_ID () is defined by this document. The format of the Notify payload for this notification is shown below. -#+caption: Sub SA Notifier -#+name: sub-sa-notifier +#+caption: Maximum Sub SA Notification +#+name: max-sub-sa-notify #+begin_src 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -537,6 +524,51 @@ that Sub SA IDs not repeat). If no SSKDF transform was negotiated, this notification MUST be ignored by peers. +** Announcing Maximum Crypt Offset + +Each peer MAY inform the other side about the maximum offset they +accept in the EESP ~Crypt Offset~ option. The other side MUST NOT +use a Crypt Offset exceeding this value (inclusive). + +Note that this is not a negotiation: each side can indicate its own +value for the maximum Crypt Offset. If a valid EESP packet is +received where the Crypt Offset exceeds the announced maximum, it +MUST be dropped, and the Child SA SHOULD be deleted. + +A new notify status type EESP_MAX_CRYPT_OFFSET () is defined by +this document. The format of the Notify payload for this notification +is shown below. + +#+caption: Maximum Crypt Offset Notification +#+name: max-crypto-offset-notify +#+begin_src + 1 2 3 +0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-----------------------------+-------------------------------+ +! Next Payload !C! RESERVED ! Payload Length ! ++---------------+---------------+-------------------------------+ +! Protocol ID ! SPI Size ! Notify Message Type ! ++---------------+---------------+-------------------------------+ +! Maximum C. O. | ++---------------+ +#+end_src + +- Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0. +- SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0. +- Notify Status Message Type (2 octets) - set to EESP_MAX_CRYPT_OFFSET (). +- Maximum Crypt Offset (1 octet) + -- specifies the maximum value for the CryptOffset field in the + EESP Crypt Offset option the sender of this notification is + accepting (measured in 4-octet units). Note that the field in the + option is only 6 bits wide. + +If a peer doesn't allow the use of the Crypt Offset option, instead +of sending the value 0, the notification SHOULD be omitted entirely. +That is, if this notification was not received by a peer, that peer +MUST not use a Crypt Offset when sending EESP packets. If a packet +with Crypt Offset option is still received, it MUST be dropped, and +the Child SA SHOULD be deleted. + * Key Derivation for Sub SAs When an EESP SA is using Sub SAs, each Sub SA (including the one @@ -628,14 +660,15 @@ document. | Value | Notify Message Status Type | Reference | |--------+----------------------------+-----------------+ | | EESP_MAX_SUB_SA_ID | [this document] | +| | EESP_MAX_CRYPT_OFFSET | [this document] | # *** Extending ESP with EESP -#Several tables in [[IKEv2-IANA]] that specify ESP as protocol -#should be extended with EESP. Should we list each table one by one or -#specify as replace ESP, with ESP, EESP.e.g in the Transform Type Values, -#replace 'IKE and ESP' with 'IKE, ESP, and EESP' +# Several tables in [[IKEv2-IANA]] that specify ESP as protocol +# should be extended with EESP. Should we list each table one by one or +# specify as replace ESP, with ESP, EESP.e.g in the Transform Type Values, +# replace 'IKE and ESP' with 'IKE, ESP, and EESP' # -#Changes the "Used In" column for the existing allocations as follows; +# Changes the "Used In" column for the existing allocations as follows; *** Sequence Number @@ -644,8 +677,8 @@ This document defines two new values in the IKEv2 "Transform Type 5 | Value | Name | Reference | |---------+-------------------------------+-----------------+ -| | 64-bit Sequential Numbers | [this document] | -| | None | [this document] | +| | 64-bit Sequential Numbers | [this document] | +| | None | [this document] | ** New IKEv2 Registries