101   Rekey may fail in case of overlapping message

Created: 04 Feb 2025

Status: Approval (Editoral)

Part: Part 4 (2018, Edition 1.1)

Links:

Page: 1

Clause: 1

Paragraph: 1

Issue

Both the client and the server in IEC 61850 can send spontaneous messages. During the rekey especially when the server sends the changedKey message the client could send a message at the exact same time based upon the old key. The server expects the message based upon the new key. What will the server do?

Proposal

The standard should specify how this "overlapping" shall be prevented/or resolved.

Discussion Created Status
After TF discussion, the addition of clarifying text was seen as sufficient.
The attachement provides an enhancement to clause 13.3.2 providing a graphical rpresentation and enhanced description of the rekey procedure. 		18 Feb 25 Approval (Editoral)
Based on TF discussion, only clarification needed on how the rekey procedure is intended (improve description) 18 Feb 25 Discussion (red)
The attachement provides the implementation proposal 17 Feb 25 Drafting Implementation
I believe that the new proposed text (by Steffen) will solve the problem. 07 Feb 25 Discussion (red)
Proposal to change point h) as following

OLD (existing text)
h)The changedKey component shall not be present in a SecPDU from the client. When the server wants to signal that will be using a new set of keys for the SecPDUs following the SecPDU in which this component is included, it shall include this component with the value TRUE. Otherwise it shall take the value FALSE or be absent. The client has to use the old keys when evaluating the SecPDUs from the server until it has seen the changedKey component with the value TRUE and shall then use the new keys for evaluating SecPDUs following the changedKey indication.

NEW (update and enhancement)
h) The changedKey component shall not be present in a SecPDU from the client before the client has received a SecPDU from the server containing this component. The change key procedure is started by the server. When the server wants to signal that it will be using a new set of keys for the SecPDUs following the SecPDU in which this component is included, it shall include this component with the value TRUE. Otherwise, it shall take the value FALSE or be absent. The client has to use the old keys when evaluating the SecPDUs from the server until it has seen the changedKey component with the value TRUE and shall then use the new keys for evaluating SecPDUs following the changedKey indication. Likewise, when the client switches to new keys, it shall use the changedKey component with the value TRUE in the next SecPDU sent to the server, which follows the received server SecPDU containing the changedKey component set to the value TRUE. Otherwise, it shall take the value FALSE or be absent. The server has to use the old keys when evaluating SecPDUs from the client until it has seen the changedKey component with the value TRUE and shall then use the new keys for evaluating SecPDUs following the changedKey indication.








05 Feb 25 Discussion (red)
Sidenote: the provided reference to page and clause makes it harder to identify the related part. The TISSUE relates likely to clause 13.3.2 f-h, describing the use of the rekey related components in the ASN.1 structure of the crypto token.

To recap that part:
- If the server wants the client to update the keys, it sets the reqRekey component. This will initiate the procedure. (point g))
- The client generates all necessary parameters and puts them in the (likely the next) response message. The old keys are still used at this point in time. Assumed both sides can now generate the new session key and be prepared for using it (point f))
- When the server wants to start using the new key, it sets the changedKey component to true indicating he would start using the new key. For the client side it requires to use the old key until the client received a message containing the changedKey component and then switch over to the new one (point h)).

An easy fix would be to utilize the same mechanism for signaling the new key usage and maintaining the old key for the client side as for the server side.
05 Feb 25 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 25.7.7.1