Internet DRAFT - draft-du-key-update-of-multiple-nodes
draft-du-key-update-of-multiple-nodes
Network Working Group Z. Du
Internet-Draft China Mobile
Intended status: Informational 18 September 2023
Expires: 21 March 2024
Key Update of Multiple Nodes in a Secure Network
draft-du-key-update-of-multiple-nodes-00
Abstract
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.
Requirements Language
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].
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 21 March 2024.
Copyright Notice
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
Du Expires 21 March 2024 [Page 1]
Internet-Draft Key Update of Multiple Nodes September 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Mechanism for Key Updating . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
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.
2. Mechanism for Key Updating
A preliminary key updating mechanism is described in this section.
The objective of the mechanism is to make sure the secure
communication.
Du Expires 21 March 2024 [Page 2]
Internet-Draft Key Update of Multiple Nodes September 2023
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.
Du Expires 21 March 2024 [Page 3]
Internet-Draft Key Update of Multiple Nodes September 2023
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.
3. IANA Considerations
TBD.
4. Security Considerations
TBD.
5. Acknowledgements
TBD.
6. References
6.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,
<https://www.rfc-editor.org/info/rfc2119>.
6.2. Informative References
[I-D.ietf-core-oscore-key-update]
Höglund, R. and M. Tiloca, "Key Update for OSCORE
(KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-key-update-05, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-key-update-05>.
Du Expires 21 March 2024 [Page 4]
Internet-Draft Key Update of Multiple Nodes September 2023
Author's Address
Zongpeng Du
China Mobile
No.32 XuanWuMen West Street
Beijing
100053
China
Email: duzongpeng@foxmail.com
Du Expires 21 March 2024 [Page 5]
