| Internet-Draft | Key Update of Multiple Nodes | September 2023 |
| Du | Expires 21 March 2024 | [Page] |
This document describes a key update mechanism for a secure network, in which each network node can maintain a temporary key to decrypt packet or make a signature for the packets.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
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 21 March 2024.¶
Copyright (c) 2023 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 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In a secure network, each node needs to maintain a temporary key to decrypt the packet information or to make a signature for the packet. Meanwhile, the temporary key needs to be updated periodically.¶
A packet needs to go though the network hop by hop, and it will be handled by multiple nodes. When the keys are being updated, in the same node, some packets may need to be decrypted or signed by the old key, and some packets may need to be signed by the new key.¶
The problem is caused by the fact that the communication is made by multiple elements along the path. In this case, not only the peer nodes join in the secure process, but also the middle nodes join into the secure process. It is different from the peer-to-peer scenario, for example the one described in [I-D.ietf-core-oscore-key-update].¶
The main idea of the document is that we can add a flag in the packet to indicate whether the new key should be used by the node or the old key should be used. One assumption of the document is that the nodes will update the keys in the same time. However, it may take a while to finish all the key update, and the traffic should not be stopped while the updating.¶
A preliminary key updating mechanism is described in this section. The objective of the mechanism is to make sure the secure communication.¶
Each node along the path should have a primary key to generate temporary keys, and we call them kti-j in this document, in which the "i" stands for the number of the node, and the "j" stands for the number of the temporary key.¶
We have two cycles for the network, and they are called the odd cycle and the even cycle. At the first odd cycle, each node uses its temporary key, called ki-a in document, to do the decryption and signature. Also, each node will also have another temporary key, ki-b, and it will be used in the even cycle.¶
In the first cycle, the ki-a is set to kti-1, and the ki-b is set to null. The ki-a is used as the active key of the Node i. The headend, which generates packets for a path, will use {kti-1} to encrypt the packet information, and the cycle flag is set to 1.¶
In the second cycle, the kti-2 of each node is generated, and the ki-b is set to kti-2. At the front part of the cycle, all the packets are with the cycle flag 1. Within the cycle, the headend will use {kti-2} instead to encrypt the packet information, and the cycle flag is set to 0. At the end of the cycle, all packets with the cycle flag 1 should have finished and disappeared, and all packets are with the cycle flag 0.¶
In the third cycle, the kti-3 of each node is generated, and the ki-a is set to kti-3. At the front part of the cycle, all the packets are with the cycle flag 0. Within the cycle, the headend will use {kti-3} instead to encrypt the packet information, and the cycle flag is set to 1. At the end of the cycle, all packets with the cycle flag 0 should have finished, and all packets are with the cycle flag 1.¶
In the fourth cycle, the kti-4 of each node is generated, and the ki-b is set to kti-4. At the front part of the cycle, all the packets are with the cycle flag 1. Within the cycle, the headend will use {kti-4} instead to encrypt the packet information, and the cycle flag is set to 0. At the end of the cycle, all packets with the cycle flag 1 should have finished and disappeared, and all packets are with the cycle flag 0.¶
Similar operation takes place afterwards.¶
In the above mechanism, for a headend, all the paths will be encrypted by using the same {kti-j}. To improve the security, we can also generate another session key, {sti-j-p}, for a specific path "p". For example, they can be generated by using the a timestamp and the {kti-j}, and will be updated accordingly when the temporary key is updated. In this case, the packet header should also carry the timestamp. Hence, the node can generate the {sti-j-p} when the packet arrives.¶
We assume that a controller exists for the key distribution. In each cycle, the kti-j of Node j will be sent to the controller. For each headend, if it want to generate a path by using the session key, it need to send a timestamp to the controller, and the controller will respond a session key for the path. Afterwards in each cycle, the session key will be updated and provide to the headend. Hence, the headend can use the {sti-j-p} to encrypt the packet.¶
TBD.¶
TBD.¶