Identifier Update for OSCORE
draft-ietf-core-oscore-id-update-05
| Document | Type | Active Internet-Draft (core WG) | |
|---|---|---|---|
| Authors | Rikard Höglund , Marco Tiloca | ||
| Last updated | 2025-10-20 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Working Group Repo
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-core-oscore-id-update-05
CoRE Working Group R. Höglund
Internet-Draft M. Tiloca
Intended status: Standards Track RISE AB
Expires: 23 April 2026 20 October 2025
Identifier Update for OSCORE
draft-ietf-core-oscore-id-update-05
Abstract
Two peers that communicate with the CoAP protocol can use the Object
Security for Constrained RESTful Environments (OSCORE) protocol to
protect their message exchanges end-to-end. To this end, the two
peers share an OSCORE Security Context and a number of related
identifiers. In particular, each of the two peers stores a Sender ID
that identifies its own Sender Context within the Security Context,
and a Recipient ID that identifies the Recipient Context associated
with the other peer within the same Security Context. These
identifiers are sent in plaintext within OSCORE-protected messages.
Hence, they can be used to correlate messages exchanged between peers
and track those peers, with consequent privacy implications. This
document defines an OSCORE ID update procedure that two peers can use
to update their OSCORE identifiers. This procedure can be run stand-
alone or seamlessly integrated in an execution of the Key Update for
OSCORE (KUDOS) procedure.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-core-oscore-id-update/.
Discussion of this document takes place on the Constrained RESTful
Environments (core) Working Group mailing list
(mailto:core@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/core/. Subscribe at
https://www.ietf.org/mailman/listinfo/core/.
Source for this draft and an issue tracker can be found at
https://github.com/core-wg/oscore-id-update.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Höglund & Tiloca Expires 23 April 2026 [Page 1]
Internet-Draft Identifier Update for OSCORE October 2025
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 23 April 2026.
Copyright Notice
Copyright (c) 2025 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Update of OSCORE Sender/Recipient IDs . . . . . . . . . . . . 4
2.1. Workflow of the ID Update Procedure . . . . . . . . . . . 5
2.1.1. Procedure Completion . . . . . . . . . . . . . . . . 6
2.2. Failure of the ID Update Procedure . . . . . . . . . . . 7
2.3. The Recipient-ID Option . . . . . . . . . . . . . . . . . 8
2.4. The Recipient-ID-Ack Option . . . . . . . . . . . . . . . 9
2.4.1. OSCORE ID Update Procedure Initiated with a Request
Message . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. Establishing New OSCORE Identifiers Ahead of Network
Migration . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3. Additional Actions for Execution . . . . . . . . . . 14
2.5. Preserving Observations Across ID Updates . . . . . . . . 15
3. Security Considerations . . . . . . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
4.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 16
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Normative References . . . . . . . . . . . . . . . . . . 17
5.2. Informative References . . . . . . . . . . . . . . . . . 18
Höglund & Tiloca Expires 23 April 2026 [Page 2]
Internet-Draft Identifier Update for OSCORE October 2025
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18
A.1. OSCORE ID Update Procedure Initiated with a Response
Message . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Failure of the OSCORE ID Update Procedure Initiated with a
Request Message . . . . . . . . . . . . . . . . . . . . . 21
Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 24
B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 24
B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 24
B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 24
B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 24
B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 24
B.6. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
When using the CoAP protocol [RFC7252], two peers can use the Object
Security for Constrained RESTful Environments (OSCORE) protocol to
protect their message exchanges end-to-end. To this end, the two
peers share an OSCORE Security Context and a number of related
identifiers.
As part of the shared Security Context, each peer stores one Sender
Context identified by a Sender ID and used to protect its outgoing
messages. Also, it stores a Recipient Context identified by a
Recipient ID and used to unprotect the incoming messages from the
other peer. That is, one's peer Sender ID (Recipient ID) is equal to
the other peer's Recipient ID (Sender ID).
When receiving an OSCORE-protected message, the recipient peer uses
its Recipient ID conveyed within the message or otherwise implied, in
order to retrieve the correct Security Context and unprotect the
message.
These identifiers are sent in plaintext within OSCORE-protected
messages and are immutable throughout the lifetime of a Security
Context, even in case the two peers migrate to a different network or
simply change their addressing information. Therefore, the
identifiers can be used to correlate messages that the two peers
exchange at different points in time or through different paths,
hence allowing to track them with the consequent privacy
implications.
Höglund & Tiloca Expires 23 April 2026 [Page 3]
Internet-Draft Identifier Update for OSCORE October 2025
In order to address this issue, this document defines an OSCORE ID
update procedure that two peers can use to update their OSCORE Sender
and Recipient IDs. For instance, two peers may want to use this
procedure before switching to a different network, in order to make
it more difficult to understand that their communication is
continuing in the new network.
The OSCORE ID update procedure can be run stand-alone or seamlessly
integrated in an execution of the Key Update for OSCORE (KUDOS)
procedure [I-D.ietf-core-oscore-key-update].
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers are expected to be familiar with the terms and concepts
related to CoAP [RFC7252], Observe [RFC7641], CBOR [RFC8949], OSCORE
[RFC8613], and KUDOS [I-D.ietf-core-oscore-key-update].
2. Update of OSCORE Sender/Recipient IDs
This section defines the procedure that two peers can perform, in
order to update the OSCORE Sender/Recipient IDs that they use in
their shared OSCORE Security Context.
When performing an update of OSCORE Sender/Recipient IDs, a peer
provides its new intended OSCORE Recipient ID to the other peer, by
means of the Recipient-ID Option defined in Section 2.3. Hereafter,
this document refers to a message including the Recipient-ID Option
as an "ID update (request/response) message". Furthermore, a peer
uses the Recipient-ID-Ack Option to confirm the chosen Recipient ID
of the other peer.
This procedure can be initiated by either peer, i.e., the CoAP client
or the CoAP server may start it by sending the first OSCORE ID update
message.
Furthermore, this procedure can be executed stand-alone, or instead
seamlessly integrated in an execution of the KUDOS procedure for
updating OSCORE keying material used in its FS mode (see Section 4 of
[I-D.ietf-core-oscore-key-update]) or no-FS mode (see Section 4.5 of
[I-D.ietf-core-oscore-key-update]).
Höglund & Tiloca Expires 23 April 2026 [Page 4]
Internet-Draft Identifier Update for OSCORE October 2025
* In the former stand-alone case, updating the OSCORE Sender/
Recipient IDs effectively results in updating part of the current
OSCORE Security Context.
That is, both peers derive a new Sender Key, Recipient Key, and
Common IV, as defined in Section 3.2 of [RFC8613]. Also, both
peers re-initialize the Sender Sequence Number and the Replay
Window accordingly, as defined in Section 3.2.2 of [RFC8613].
Since the same Master Secret is preserved, forward secrecy is not
achieved.
As defined in Section 2.4.3, the two peers must take additional
actions to ensure a safe execution of the OSCORE ID update
procedure.
The new OSCORE Sender/Recipient IDs MUST NOT be used with the
OSCORE Security Context CTX_OLD, and MUST NOT be used with the
temporary OSCORE Security Context CTX_TEMP used to protect the
first KUDOS message of a KUDOS execution.
A peer MUST NOT initiate an OSCORE ID update procedure with another
peer, if it has another such procedure ongoing with that other peer.
Upon receiving a valid, first ID update message, a peer MUST continue
the procedure and send a following ID update message, except in the
case any of the conditions for failing or aborting the procedure
apply (see Section 2.2}).
2.1. Workflow of the ID Update Procedure
This section describes the workflow of the OSCORE ID Update procedure
in detail.
The procedure begins when either peer:
* Sends a message including the Recipient-ID Option, or
* Receives such a message from the other peer.
During the procedure a peer decides on a value of Recipient ID to
offer to the other peer and use as value of the Recipient-ID Option,
and continues offering that value until the procedure is completed.
Once the procedure has started a peer shall follow the instructions
below:
*Sending the Next Message*
Höglund & Tiloca Expires 23 April 2026 [Page 5]
Internet-Draft Identifier Update for OSCORE October 2025
* The first messages sent using CTX_A, the current shared OSCORE
Security Context, after the procedure has started must include the
Recipient-ID Option, if this peer hasn't offered its Recipient ID
already.
- Note that this also informs the other peer of support for the
ID update procedure.
*Acknowledgment*
* If a peer has received a valid message from the other peer
including the Recipient-ID Option, it must include the Recipient-
ID-Ack Option in subsequent messages.
* The value of Recipient-ID-Ack Option, if used, should be the
Recipient ID received from the other peer.
*Sending Subsequent Messages*
A peer must send one message with the Recipient ID Option according
to the following:
* A local timer, REPEAT_TIMER, should be maintained during the
procedure. It first starts when the procedure starts. It is
RECOMMENDED that the initial time of REPEAT_TIMER is equal to
MAX_TRANSMIT_WAIT (see Section 4.8.2 of [RFC7252]).
- If the timeout expires, the next sent message must include the
Recipient ID option and, if applicable, the Recipient-ID-Ack
Option with the last received Recipient ID. When that message
is sent the timer REPEAT_TIMER restarts.
2.1.1. Procedure Completion
The procedure concludes under one of the following conditions:
*Successful Confirmation*
The procedure succeeds if a peer has received and successfully
verified at least three message from the other peer containing the
Recipient-ID-Ack Option, and sent at least two messages containing
the Recipient-ID-Ack Option. At this point:
* It is safe to delete CTX_A. This does not mean that CTX_A has to
be deleted at this point.
* CTX_B is now considered valid and can be used (e.g., following
network migration).
Höglund & Tiloca Expires 23 April 2026 [Page 6]
Internet-Draft Identifier Update for OSCORE October 2025
*Failure*
During the procedure a timer, ENDING_TIMER, is maintained and started
when the procedure starts. The initial time of ENDING_TIMER should
be at least 3 times bigger than the initial time of REPEAT_TIMER. If
the ENDING_TIMER expires, and the procedure times out without
confirmation:
* The offered Recipient ID must be discarded and added to the list
of IDs to prevent reuse.
2.2. Failure of the ID Update Procedure
The following section describes cases where the OSCORE ID update
procedure fails, or must to be aborted by one of the peers.
Upon receiving a valid first ID update message, a peer MUST abort the
ID update procedure, in the following case:
* The received ID update message is not a KUDOS message (i.e., the
OSCORE ID update procedure is being performed stand-alone) and the
peer has no eligible Recipient ID to offer (see Section 2.4.3).
Upon receiving a valid ID update message, a peer MUST abort the ID
update procedure, in the following case:
* The received ID update message contains a Recipient-ID option with
a length that exceeds the maximum length of OSCORE Sender/
Recipient IDs for the AEAD algorithm in use for the OSCORE
Security Context shared between the peers. This is the case when
the length of the Recipient-ID option exceeds the length of the
AEAD nonce minus 6 (see Section 3.3 of [RFC8613]).
If, after receiving an ID update message as CoAP request, a peer
aborts the ID update procedure, the peer MUST also reply to the
received ID update request message with a protected 5.03 (Service
Unavailable) error response. The error response MUST NOT include the
Recipient-ID Option, and its diagnostic payload MAY provide
additional information. When receiving the error response, the peer
terminates the OSCORE IDs procedure as failed.
Höglund & Tiloca Expires 23 April 2026 [Page 7]
Internet-Draft Identifier Update for OSCORE October 2025
When the OSCORE ID update procedure is integrated into the execution
of the KUDOS procedure, it is possible that the KUDOS procedure
succeeds while the OSCORE ID update procedure fails. In such case,
the peers continue their communications using the newly derived
OSCORE Security Context CTX_NEW obtained from the KUDOS procedure,
and still use the old Sender and Recipient IDs. That is, any
Recipient IDs conveyed in the exchanged Recipient-ID Options is not
considered.
Conversely, the OSCORE ID update procedure may succeed while the
KUDOS procedure fails. As long as the peers have exchanged a pair of
OSCORE-protected request and response that conveyed their desired new
Recipient IDs in the Recipient-ID Option, the peers start using those
IDs in their communications.
2.3. The Recipient-ID Option
The Recipient ID-Option defined in this section has the properties
summarized in Table 1, which extends Table 4 of [RFC7252]. That is,
the option is elective, safe to forward, part of the cache key, and
not repeatable.
+=======+===+===+===+===+==============+========+========+=========+
| No. | C | U | N | R | Name | Format | Length | Default |
+=======+===+===+===+===+==============+========+========+=========+
| TBD24 | | | | | Recipient-ID | opaque | any | (none) |
+-------+---+---+---+---+--------------+--------+--------+---------+
Table 1: The Recipient-ID Option. C=Critical, U=Unsafe,
N=NoCacheKey, R=Repeatable
Note to RFC Editor: Following the registration of the CoAP Option
Number 24, please replace "TBD24" with "24" in the figure above.
Then, please delete this paragraph.
The option value can have an arbitrary length, including zero length
to indicate intent to use the empty string as Recipient ID.
Implementations can limit its length to that of the longest supported
Recipient ID.
This document particularly defines how this option is used in
messages protected with OSCORE. That is, when the option is included
in an outgoing message, the option value specifies the new OSCORE
Recipient ID that the sender endpoint intends to use with the other
endpoint sharing the OSCORE Security Context.
Höglund & Tiloca Expires 23 April 2026 [Page 8]
Internet-Draft Identifier Update for OSCORE October 2025
Therefore, the maximum length of the option value is equal to the
maximum length of OSCORE Sender/Recipient IDs. As defined in
Section 3.3 of [RFC8613], this is determined by the size of the AEAD
nonce of the used AEAD Algorithm in the OSCORE Security Context.
If the length of the Recipient ID included in the Recipient-ID option
is zero, the option value SHALL be empty (Option Length = 0).
The Recipient-ID Option is of class E in terms of OSCORE processing
(see Section 4.1 of [RFC8613]).
2.4. The Recipient-ID-Ack Option
The Recipient ID-Ack-Option defined in this section has the
properties summarized in Table 2, which extends Table 4 of [RFC7252].
That is, the option is elective, safe to forward, part of the cache
key, and not repeatable.
+=======+=+=+===+===+==================+========+========+=========+
| No. |C|U| N | R | Name | Format | Length | Default |
+=======+=+=+===+===+==================+========+========+=========+
| TBD32 | | | | | Recipient-ID-Ack | opaque | any | (none) |
+-------+-+-+---+---+------------------+--------+--------+---------+
Table 2: The Recipient-ID-Ack Option. C=Critical, U=Unsafe,
N=NoCacheKey, R=Repeatable
Note to RFC Editor: Following the registration of the CoAP Option
Number 32, please replace "TBD32" with "32" in the figure above.
Then, please delete this paragraph.
This document particularly defines how this option is used in
messages protected with OSCORE. That is, when the option is included
in an outgoing message, the option value confirms the new OSCORE
Recipient ID that the recipient endpoint has chosen for this sender
endpoint.
The Recipient-ID-Ack Option is of class E in terms of OSCORE
processing (see Section 4.1 of [RFC8613]).
2.4.1. OSCORE ID Update Procedure Initiated with a Request Message
Figure 1 shows an example of the OSCORE ID update procedure, run
stand-alone and initiated by the client sending a request message.
On each peer, SID and RID denote the OSCORE Sender ID and Recipient
ID of that peer, respectively. An example where the server initiates
the procedure is shown in Appendix A.1.
Höglund & Tiloca Expires 23 April 2026 [Page 9]
Internet-Draft Identifier Update for OSCORE October 2025
Client Server
| |
CTX_A { | | CTX_A {
SID = 0x01 | | SID = 0x00
RID = 0x00 | | RID = 0x01
} | | }
| |
| Request #1 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
| Recipient-ID: 0x42 |
| ... |
| Application Payload |
| } |
| |
| Response #1 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Recipient-ID: 0x78 |
| Recipient-ID-Ack: 0x42 |
| ... |
| Application Payload |
| } |
| |
| |
| |
| Request #2 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
| Recipient-ID-Ack: 0x78 |
| ... |
| Application Payload |
| } |
| |
Höglund & Tiloca Expires 23 April 2026 [Page 10]
Internet-Draft Identifier Update for OSCORE October 2025
| Response #2 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Recipient-ID-Ack: 0x42 |
| Application Payload |
| } |
| |
| |
| Request #3 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
| Recipient-ID-Ack: 0x78 |
| ... |
| Application Payload |
| } |
| |
| Response #3 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Recipient-ID-Ack: 0x42 |
| Application Payload |
| } |
| |
Safe to | |
discard | |
CTX_A | |
| |
| Request #4 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
Höglund & Tiloca Expires 23 April 2026 [Page 11]
Internet-Draft Identifier Update for OSCORE October 2025
| Recipient-ID-Ack: 0x78 |
| ... |
| Application Payload |
| } |
| |
| | Safe to
| | discard
| | CTX_A
| |
| Response #4 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Application Payload |
| } |
| |
Figure 1: Example of the OSCORE ID update procedure initiated
with a request message
Before the OSCORE ID update procedure starts, the client (the server)
shares with the server (the client) an OSCORE Security Context CTX_A
with Sender ID 0x01 (0x00) and Recipient ID 0x00 (0x01).
When starting the OSCORE ID update procedure, the client determines
its new intended OSCORE Recipient ID 0x42. Then, the client prepares
a CoAP request targeting an application resource at the server. The
request includes the Recipient-ID Option, with value the client's new
Recipient ID 0x42.
The client protects the request with CTX_A, i.e., by using the keying
material derived from the client's current Sender ID 0x01. The
protected request specifies the client's current Sender ID 0x01 in
the 'kid' field of the OSCORE Option. After that, the client sends
the request to the server as Request #1.
Upon receiving, decrypting, and successfully verifying the OSCORE
message Request #1, the server retrieves the value 0x42 from the
Recipient-ID Option, and determines its new intended OSCORE Recipient
ID 0x78. Then, the server prepares a CoAP response including the
Recipient-ID Option, with value the server's new Recipient ID 0x78,
and the Recipient-ID-Ack Option, with value the client's offered
Recipient ID 0x42.
Höglund & Tiloca Expires 23 April 2026 [Page 12]
Internet-Draft Identifier Update for OSCORE October 2025
The server protects the response with CTX_A, i.e., by using the
keying material derived from the server's current Sender ID 0x00.
After that, the server sends the response to the client.
Next, the client sends the OSCORE message Request #2, which is
protected with CTX_A and includes the Recipient-ID-Ack Option, with
value the server's offered Recipient ID 0x78.
From this point, following messages exchanges between the peers will
include the Recipient-ID-Ack Option. A peer will only stop including
that option when it has verified 3 messages from the other peer
containing the Recipient-ID-Ack Option.
Upon receiving, decrypting, and successfully verifying the OSCORE
message Response #3, the client considers 0x78 and 0x42 as the new
Sender ID and Recipient ID to use when deriving CTX_B. Practically,
the client can install a new OSCORE Security Context CTX_B where: i)
its Sender ID and Recipient ID are 0x78 and 0x42, respectively; ii)
the Sender Sequence Number and the Replay Window are re-initialized
(see Section 3.2.2 of [RFC8613]); iii) anything else is like in the
OSCORE Security Context CTX_A.
Upon receiving, decrypting, and successfully verifying the OSCORE
message Request #4, the server considers 0x42 and 0x78 as its new
Sender ID and Recipient ID to use for CTX_B. Practically, the server
installs a new OSCORE Security Context CTX_A where: i) its Sender ID
and Recipient ID are 0x42 and 0x78, respectively; ii) the Sender
Sequence Number and the Replay Window are re-initialized (see
Section 3.2.2 of [RFC8613]); iii) anything else is like in the OSCORE
Security Context CTX_A.
At this point both client and server are in a position to derive
CTX_B already, or wait to do it. Regardless they are both able to
start using CTX_B, e.g., after network migration.
2.4.2. Establishing New OSCORE Identifiers Ahead of Network Migration
Peers may use the OSCORE ID update procedure to establish new OSCORE
IDs in advance of a network change. However, peers SHOULD NOT begin
using these new identifiers on the current network prior to network
migration. Using a new identifier on the old network, or using the
old identifiers on the new network, would allow observers to
correlate activity across networks, defeating the unlinkability that
updating the OSCORE IDs is intended to provide. To be effective, new
identifiers SHOULD only be used for sending OSCORE protected messages
once the network migration is completed. Establishing new OSCORE IDs
ahead of time ensures that migration can proceed without delay, but
care must be taken to ensure that premature use of the identifiers
Höglund & Tiloca Expires 23 April 2026 [Page 13]
Internet-Draft Identifier Update for OSCORE October 2025
does not enable linkability.
To accomplish this, the peers execute the ID update procedure as
normal, with the following difference: the peers must not begin using
the OSCORE Security Context CTX_B until after the network migration
has taken place. Thus, both peers will be in the position to derive
CTX_B, but will not transition to use it until the first request
protected with CTX_B is transmitted in the new network, that is after
network migration. Note that peers may want to retain CTX_A to have
available for migration back to the old network.
2.4.3. Additional Actions for Execution
After having experienced a loss of state, a peer MUST NOT participate
in a stand-alone OSCORE ID update procedure with another peer, until
having performed a full-fledged establishment/renewal of an OSCORE
Security Context with the other peer (e.g., by running KUDOS
[I-D.ietf-core-oscore-key-update] or the authenticated key
establishment protocol EDHOC [RFC9528]).
More precisely, a peer has experienced a loss of state if it cannot
access the latest snapshot of the latest OSCORE Security Context
CTX_OLD or the whole set of OSCORE Sender/Recipient IDs that have
been used with the triplet (Master Secret, Master Salt, ID Context)
of CTX_OLD. This can happen, for instance, after a device reboots.
Furthermore, when participating in a stand-alone OSCORE ID update
procedure, a peer performs the following additional steps.
* When a peer sends an ID update message, the value of the
Recipient-ID Option that the peer specifies as its new intended
OSCORE Recipient ID MUST fulfill both the following conditions: it
is currently available as Recipient ID to use for the peer (see
Section 3.3 of [RFC8613]); and the peer has never used it as
Recipient ID with the current triplet (Master Secret, Master Salt,
ID Context).
* When receiving an ID update message, the peer MUST abort the
procedure if it has already used the identifier specified in the
Recipient-ID Option as its own Sender ID with the current triplet
(Master Secret, Master Salt, ID Context).
In order to fulfill the conditions above, a peer has to keep track of
the OSCORE Sender/Recipient IDs that it has used with the current
triplet (Master Secret, Master Salt, ID Context) since the latest
update of the OSCORE Master Secret (e.g., performed by running
KUDOS).
Höglund & Tiloca Expires 23 April 2026 [Page 14]
Internet-Draft Identifier Update for OSCORE October 2025
2.5. Preserving Observations Across ID Updates
When having run the OSCORE ID update procedure stand-alone and
starting to use CTX_B, or having run the OSCORE ID update procedure
integrated in an execution of KUDOS, the following holds if Observe
[RFC7641] is supported, in order to preserve ongoing observations
beyond a change of OSCORE identifiers.
* If a peer intends to keep active beyond an update of its Sender ID
the observations where it is acting as CoAP client, then the peer:
- MUST store the value of the 'kid' parameter from the original
Observe requests, and retain it for the whole duration of the
observations, throughout which the client MUST NOT update the
stored value associated with the corresponding Observe
registration request; and
- MUST use the stored value of the 'kid' parameter from the
original Observe registration request as value for the
'request_kid' parameter in the external_aad structure (see
Section 5.4 of [RFC8613]), when verifying notifications for
that observation as per Section 8.4.2 of [RFC8613].
* If a peer is acting as CoAP server in an ongoing observation, then
the peer:
- MUST store the value of the 'kid' parameter from the original
Observe registration request, and retain it for the whole
duration of the observation, throughout which the peer MUST NOT
update the stored value associated with the corresponding
Observe registration request; and
- MUST use the stored value of the 'kid' parameter from the
original Observe registration request as value for the
'request_kid' parameter in the external_aad structure (see
Section 5.4 of [RFC8613]), when protecting notifications for
that observation as per Section 8.3.1 of [RFC8613].
3. Security Considerations
The same security considerations as in [RFC8613] and
[I-D.ietf-core-oscore-key-update] hold for this document.
The OSCORE ID update procedure is a mechanism to mitigate the risk of
tracking by on-path adversaries. By enabling endpoints to update
their identifiers, either in response to specific events or on a
regular basis, this approach helps prevent correlations that could
otherwise be drawn between OSCORE messages on different networks.
Höglund & Tiloca Expires 23 April 2026 [Page 15]
Internet-Draft Identifier Update for OSCORE October 2025
While the ID update procedure helps reduce linkability across
networks, the change of IDs alone might not completely prevent
adversaries from recognizing traffic patterns that reveal message
ordering or frequency. That is, the procedure becomes more effective
if combined with the protection and/or change of other information
that can help identify endpoints across different networks.
In that spirit, when a peer installs a new OSCORE Security Context as
a result of the OSCORE ID update procedure, it re-initializes the
Sender Sequence Number to 0. That prevents an adversary from
obviously tracking the peer by leveraging the Partial IV of observed
messages, since the Partial IV value does not predictably continue
from the last known value that was used in the previous network.
Building on that, the peer can in fact re-initialize the Sender
Sequence Number to a value greater than 0, thus making tracking
further difficult.
Likewise, other information such as addressing information, may still
be used to track the peers. Thus, it is recommended to combine the
usage of the OSCORE ID update procedure also with the following, upon
network migration:
* Changing the network address (e.g., intentionally, or due to
mobility, or NAT rebinding).
* Changing the link-layer address (e.g., MAC address randomization).
Furthermore, it is recommended that a peer does not start using its
newly established OSCORE Sender ID until after network migration, in
order to mitigate tracking attempts.
4. IANA Considerations
This document has the following actions for IANA.
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
with the RFC number of this specification and delete this paragraph.
4.1. CoAP Option Numbers Registry
IANA is asked to enter the following entries to the "CoAP Option
Numbers" registry within the "Constrained RESTful Environments (CoRE)
Parameters" registry group.
Höglund & Tiloca Expires 23 April 2026 [Page 16]
Internet-Draft Identifier Update for OSCORE October 2025
+========+==================+============+
| Number | Name | Reference |
+========+==================+============+
| TBD24 | Recipient-ID | [RFC-XXXX] |
+--------+------------------+------------+
| TBD32 | Recipient-ID-Ack | [RFC-XXXX] |
+--------+------------------+------------+
Table 3: New CoAP Option Numbers
Note to RFC Editor: Following the registration of the CoAP Option
Number 24, please replace "TBD24" with "24" in the table above.
Then, please delete this paragraph. Note to RFC Editor: Following
the registration of the CoAP Option Number 32, please replace "TBD32"
with "32" in the table above. Then, please delete this paragraph.
5. References
5.1. Normative 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-11, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-key-update-11>.
[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/rfc/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/rfc/rfc7641>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Höglund & Tiloca Expires 23 April 2026 [Page 17]
Internet-Draft Identifier Update for OSCORE October 2025
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/rfc/rfc8613>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
5.2. Informative References
[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
DOI 10.17487/RFC9528, March 2024,
<https://www.rfc-editor.org/rfc/rfc9528>.
Appendix A. Examples
This appendix provides examples where the OSCORE ID update procedure
is used. In particular:
* Appendix A.1 shows an example of the OSCORE ID update procedure
initiated by the server sending a response message.
* Appendix A.2 shows an example of the OSCORE ID update procedure
initiated by the client sending a request message where the
procedure fails to complete.
A.1. OSCORE ID Update Procedure Initiated with a Response Message
Figure 2 shows an example of the OSCORE ID update procedure, run
stand-alone and initiated by the server sending a response message.
On each peer, SID and RID denote the OSCORE Sender ID and Recipient
ID of that peer, respectively. The prerequisites and the actions
taken by the peers involved are aligned with what is described in
Section 2.4.1, except that it is the server that takes the initiative
to perform the OSCORE ID update procedure.
Client Server
| |
CTX_A { | | CTX_A {
SID = 0x01 | | SID = 0x00
RID = 0x00 | | RID = 0x01
} | | }
| |
| Request #1 |
|---------------------------------->| /temp
Höglund & Tiloca Expires 23 April 2026 [Page 18]
Internet-Draft Identifier Update for OSCORE October 2025
| OSCORE { |
| ... |
| kid: 0x01 |
| } |
| Encrypted Payload { |
| ... |
| Application Payload |
| } |
| |
| Response #1 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Recipient-ID: 0x42 |
| ... |
| Application Payload |
| } |
| |
| |
| |
| Request #2 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
| Recipient-ID: 0x78 |
| Recipient-ID-Ack: 0x42 |
| ... |
| Application Payload |
| } |
| |
| Response #2 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Recipient-ID-Ack: 0x78 |
| ... |
| Application Payload |
| } |
Höglund & Tiloca Expires 23 April 2026 [Page 19]
Internet-Draft Identifier Update for OSCORE October 2025
| |
| |
| Request #3 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
| Recipient-ID-Ack: 0x42 |
| Application Payload |
| } |
| |
| Response #3 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Recipient-ID-Ack: 0x78 |
| ... |
| Application Payload |
| } |
| |
| |
| |
| |
| |
| Request #4 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
| Recipient-ID-Ack: 0x42 |
| Application Payload |
| } |
| |
| | Safe to
| | discard
| | CTX_A
| |
| Response #4 |
|<----------------------------------| Protect
Höglund & Tiloca Expires 23 April 2026 [Page 20]
Internet-Draft Identifier Update for OSCORE October 2025
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
Safe to | Recipient-ID-Ack: 0x78 |
discard | ... |
CTX_A | Application Payload |
| } |
| |
Figure 2: Example of the OSCORE ID update procedure initiated
with a response message
A.2. Failure of the OSCORE ID Update Procedure Initiated with a Request
Message
Figure 3 shows an example of the OSCORE ID update procedure, run
stand-alone and initiated by the client sending a request message
where the procedure fails to complete due to the server not including
the Recipient-ID-Ack option or the Recipient-ID in its response
messages. On each peer, SID and RID denote the OSCORE Sender ID and
Recipient ID of that peer, respectively. This example assumes that
the value of the REPEAT_TIMER on the client is such that it expires
between each request the client sends.
The client repeatedly tries sending requests to the client including
the Recipient-ID option, but does not receive acknowledgments in the
form of responses containing the Response-ID-Ack option from the
server. Thus the client eventually reaches the expiration of its
ENDING_TIMER, aborts the OSCORE ID update procedure, and proceeds to
continue communication with normal OSCORE messages.
Client Server
| |
CTX_A { | | CTX_A {
SID = 0x01 | | SID = 0x00
RID = 0x00 | | RID = 0x01
} | | }
| |
| Request #1 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
Höglund & Tiloca Expires 23 April 2026 [Page 21]
Internet-Draft Identifier Update for OSCORE October 2025
| Recipient-ID: 0x42 |
| ... |
| Application Payload |
| } |
| |
| Response #1 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Application Payload |
| } |
| |
| |
| |
| Request #2 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
| Recipient-ID: 0x42 |
| ... |
| Application Payload |
| } |
| |
| Response #2 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Application Payload |
| } |
| |
| |
| Request #3 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
Höglund & Tiloca Expires 23 April 2026 [Page 22]
Internet-Draft Identifier Update for OSCORE October 2025
| ... |
| Recipient-ID: 0x42 |
| ... |
| Application Payload |
| } |
| |
| Response #3 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Application Payload |
| } |
| |
ENDING_ | |
TIMER | |
expired | |
| |
| Request #4 |
Protect |---------------------------------->| /temp
with CTX_A | OSCORE { |
| ... |
| kid: 0x01 | Verify
| } | with CTX_A
| Encrypted Payload { |
| ... |
| Application Payload |
| } |
| |
| |
| |
| Response #4 |
|<----------------------------------| Protect
| OSCORE { | with CTX_A
| ... |
Verify | } |
with CTX_A | Encrypted Payload { |
| ... |
| Application Payload |
| } |
| |
Figure 3: Example of the OSCORE ID update procedure failing when
initiated with a request message
Höglund & Tiloca Expires 23 April 2026 [Page 23]
Internet-Draft Identifier Update for OSCORE October 2025
Appendix B. Document Updates
This section is to be removed before publishing as an RFC.
B.1. Version -04 to -05
* Editorial updates.
* Add additional message flow examples, including a failure case.
B.2. Version -03 to -04
* Fixes in presenting the new approach.
* Early recommendations for initial values of timers.
B.3. Version -02 to -03
* Editorial improvements.
* Improved security considerations.
* Using the ID update procedure ahead of network migration and
switching to new IDs after migration.
* Update design more in line with KUDOS.
B.4. Version -01 to -02
* Split long section into subsections.
* Updated references.
B.5. Version -00 to -01
* Revised and extended error handling.
* Specify that the Recipient-ID option may need to be empty.
* Failure cases when running the ID update procedure integrated with
KUDOS.
* Clarifications and editorial improvements.
B.6. Version -00
* Split out material from Key Update for OSCORE draft into this new
document.
Höglund & Tiloca Expires 23 April 2026 [Page 24]
Internet-Draft Identifier Update for OSCORE October 2025
* Extended terminology.
* Editorial improvements.
Acknowledgments
The authors sincerely thank Christian Amsüss, Carsten Bormann, John
Preuß Mattsson, and Göran Selander for their feedback and comments.
The work on this document has been partly supported by VINNOVA and
the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020
projects SIFIS-Home (Grant agreement 952652) and ARCADIAN-IoT (Grant
agreement 101020259).
Authors' Addresses
Rikard Höglund
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Email: rikard.hoglund@ri.se
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Email: marco.tiloca@ri.se
Höglund & Tiloca Expires 23 April 2026 [Page 25]