Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE)

1.2. Use Cases Considered

Based on terminology from Section 3.1 of [RFC9171], the four data plane interaction points between a BP Agent (BPA) and other entities are shown for two agents in Figure 2. For simplicity that diagram shows a situation where there is reachability between the nodes in one direction, but typically reachability between nodes would be in both directions (via similar or dissimilar convergence layer types and/or hop counts).¶

Two of the interaction points are with application(s) registered as endpoints in the BPA (transmit and deliver) and two are with underlying convergence layer adapter(s) used to transport bundles between BPAs (forward and receive) for each hop. Within a BPA there is logic about how and when to deliver, forward, retain, delete, discard, or some combination of those actions which are defined in Section 5 of [RFC9171]. This logic is indicated in later diagrams by the "(Decide)" label inside a BPA block.¶

      +---------------+                  +---------------+
      |   Registered  |                  |   Registered  |
      | Application(s)|                  | Application(s)|
      +---------------+                  +---------------+
        |           ^                      |           ^
Transmit|           |Deliver       Transmit|           |Deliver
        v           |                      v           |
   +----------------+----+            +----------------+----+
   |                     |            |                     |
   |      BP Agent       |            |      BP Agent       |
   |                     |            |                     |
   +----------------+----+            +----------------+----+
        ^           |                      ^           |
 Receive|           |Forward        Receive|           |Forward
        |           v                      |           v
      +-+-------------+                  +-+-------------+
      | CL Adapter(s) |                  | CL Adapter(s) |
      +---------------+                  +-------------+-+
        ^           |                      ^           |
        |           v                      |           v
~---------+       +-----------~  ~---------+-+       +--------~
          |       |     Forwarding Hop(s)    |       |
~---------+       +-----------~  ~-----------+       +--------~

This document considers two principal use cases to narrow the scope of discussion, each described in the following subsections. More complex use cases can be achieved by this protocol, either by more complex interaction with a BPSec entity or the use of techniques such as BIBE of [I-D.ietf-dtn-bibect] to perform secure tunneling between pairs of security gateway nodes.¶

        |                                              ^
Transmit|                                              |Deliver
        v                                              |
   +----+----------------+            +----------------+----+
   |  Source             |            |             Accept  |
   |       \             |            |             /       |
   |       (Decide)      |            |      (Decide)       |
   |              \      |            |      /              |
   |               \     |            |     /               |
   +----------------+----+            +----+----------------+
                    |                      ^
                    |Forward        Receive|
                    v                      |
                  +-----------~  ~---------+-+
                  |     Forwarding Hop(s)    |
                  +-----------~  ~-----------+

        |                                          ^
Transmit|                                          |Deliver
        v                                          |
   +----+----------------+        +----------------+----+
   |     \               |        |               /     |
   |      \              |        |              /      |
   |      (Decide)       |        |       (Decide)      |
   |      /       \      |        |      /       \      |
   |     /       Source  |        |  Accept       \     |
   +----+-----------+----+        +----+-----------+----+
        ^           |                  ^           |
 Receive|           |Forward    Receive|           |Forward
        |           v                  |           v
                  +--------------------+-+
                  |    Forwarding Hop    |
                  +----------------------+

2.1. Content Key Lifecycle Management

Within each SA, both primary and secondary, there are some number of content keys (CKs) available for use in the data plane. The primary SA content keys are used for AEAD of SAFE PDUs themselves, while secondary SA content keys are for BPSec operations on other traffic.¶

The primary SA has an implicit pair of content keys created as part of the Initial Authentication (IA) activity, each with a key identifier (KID) derived from and the same length as the primary security association identifier (SAI). All other KIDs of primary and secondary SAs are explicitly chosen by the entity which would use that key as the security source (i.e., the TX side of the data plane).¶

Within a single SA, the lifecycle of a single CK is depicted in Figure 6 where "Entity A" is the TX end of that key and "Entity B" is the RX end. The optional CK Prekey activity and its public key data is used to ensure forward secrecy of the CK when desired by the TX end. The CK Discard activity is used to inform the RX end when the CK will no longer be used for security operations and it is safe to be discarded.¶

+--------+               +--------+
|Entity A|               |Entity B|
|(TX end)|               |(RX end)|
+--------+               +--------+
    |<===== SA Creation ====>|
    |          ...           |
    |                        |
    |        optional        |
    |        CK Prekey       |
    |<-----------------------+
    |- - - - - - - - - - - ->|
    |                        |
    |       CK Creation      |
    +----------------------->|
    |<- - - - - - - - - - - -|
    |                        |
    |        Use CK in       |
    |        data plane      |
    +----------------------->|
    +----------------------->|
    |                        |
    |        optional        |
    |        CK Discard      |
    +----------------------->|
    |<- - - - - - - - - - - -|

An important aspect that distinguishes security associations from their constituent content keys is that the SA is parameterized to determine which traffic (either SAFE PDUs or data plane traffic) is covered by security and how that security is applied but does not contain any intrinsic time-variance, while each CK is parameterized to have a single validity time interval bounding its use over wall-clock time. This means that the SA lifecycle is managed in wall-clock time by activities between SAFE entities, specifically SA Creation (SC) and SA Teardown (ST). Within each SA, the CKs intrinsic time-variance allows pre-planning a sequence of keys with future validity to enable continuous operation by rolling-over content keys as they expire in wall-clock time as illustrated in Figure 7 for a single data direction. All of those CKs can be created immediately after SC creation with future validity times.¶

 (SC) (CC)                             (ST)
  |    |                                 |
  +--------------------------------------+
  |         Security Association         |
  +--------------------------------------+
       |
  +----------+
  |   CK #1  |
  +----------+
       |   +----------------+
       +-->|      CK #2     |
       |   +----------------+
       |                +--------------+
       +--------------->|     CK #3    |
                        +--------------+

          =----- timeline ----->

2.2. Relationship to EDHOC

This protocol embeds EDHOC as the messaging structure and behavior of the Initial Authentication (IA) activity type. Because the IA activity is the very beginning of a conversation between two SAFE entities, the packetization behavior during the IA activity is a special case containing a single EDHOC message in each PDU. This also means that during the IA activity EDHOC is responsible for confidentiality of SAFE data as critical EAD items. After the IA has finished and a primary SA is established, confidentiality is provided by an application-layer use of COSE encryption (see Section 4.4) using EDHOC session parameters.¶

2.3. Relationship to BPSec

This SAFE protocol functions as a control plane for establishing secondary SAs, which are then used to provide symmetric content keys to be used by BPSec for data plane security operations on individual target blocks within specific bundles as described in Section 1.2. The scoping of each secondary SA includes a BPSec security context identifier and its options for which each derived content key is authorized to be used. It is up to BPSec policy on each of the SAFE peer nodes to enforce those authorized uses as the mandatory security source and mandatory security acceptor for matching flows in each direction.¶

A secondary SA is scoped by the following aspects which inform BPSec policy on each peer node.¶

Security Mode:

This determines when and where security operations are sourced and accepted within each node.¶

Validity Time Interval:

This bounds the SA to an interval of time.¶

Endpoint Selectors:

This is an EID pattern used to filter by the source and destination of bundle traffic.¶

Security Operation Selectors:

This determines the security service (integrity or confidentiality) and target block types to secure.¶

Key Use Selectors:

This is a specific BPSec security context and options for using that context with the chosen security service.¶

2.4. Credential Sources

In the typical use of IKEv2 [RFC7296], TLS [RFC8446], or DTLS [RFC9147] the full credentials (and in the case of PKIX certificates, full certificate chains) are carried in the protocol exchanges. Because the original target for EDHOC was constrained networks, the credentials themselves are purposefully omitted from the EDHOC messages and instead only credential identifiers are exchanged Section 3.5.3 of [RFC9528].¶

Part of the configuration for each SAFE entity is a set of peer information (see Section 3.1), each of which contains a set of validated credentials and their root-of-trust for that peer. It is still possible for SAFE entities to provide actual credential data, which itself is kept confidential as part of the secure channel established by EDHOC.¶

2.5. Extensibility

The protocol defined in this document defines a basic set of modes and data types which are expected to be suitable for many bundle security use cases. But the protocol uses extensible IANA registries (see Section 12.3) which allow future specifications to define additional well-known code points. And each registry has a reserved block to allow private networks to make use of private code points tailored to their specific needs.¶

3.1. Participating Peers

In order to set appropriate retransmission timers, the local entity needs to know expected timing information for each participating peer node.¶

For the two stores of credential types in the Participating Peers information base, the detailed information present consists of an ordered list of entries, each containing the following.¶

Credential Type:

One of the "COSE Header Parameters" registry values from [IANA-COSE] which identifies a credential type:¶

• c5t (22), c5u (23), c5c (25) to identify a C509 end-entity certificate¶
• x5t (34), x5u (35), x5chain (33) to identify an X509 end-entity certificate¶
• kid (4) to identify a pre-shared symmetric key (PSK) leave this in?¶

Trust Anchors:

One or more type-specific root authority credentials to use as trust anchors for validating end-entity credentials.¶

Validated Credentials:

A set of credentials which has already been validated in accordance with the profile in Section 10 against the trust anchors in this entry. Each of these credentials is supplied from outside of the SAFE entity. For TX credentials, this represents local identity configuration for the peer. For RX credentials, this is from peer discovery or pre-agreement with the peer.¶

3.2. Activity States

Each SAFE entity maintains a table of in-progress activities and their associated metadata, with logical columns as indicated in Table 2.¶

While the last received step is less than the last sent step, it means that the local entity is waiting for an acknowledging message. After the final message of an activity is received, the associated table row is removed as there is no need to maintain long-term bookkeeping of finished activities. TBD about row removal timer and ignoring late duplicate messages.¶

3.3. Primary Security Associations

Each primary SA allows SAFE entities to provide PDU-level confidentiality and is used as the source of a shared secret from which secondary SAs can be derived, as depicted in Figure 5. The state of each primary SA known to the local entity has logical columns as indicated in Table 3.¶

A primary SA covers traffic in both directions between the two peers participating in the SA. The primary SA has no specific endpoint selectors because each is used for security between the SAFE entities themselves rather than any other, data plane traffic.¶

The information in Table 4 is implicitly scoped to a single primary SA and does not have an explicit relationship in that table. An entity SHOULD remove any TX Content Key when the wall-clock time advances past the end of its validity time interval.¶

The information in Table 5 is implicitly scoped to a single primary SA and does not have an explicit relationship in that table. An entity SHOULD remove any RX Content Key when the wall-clock time advances past the end of its validity time interval.¶

The information in Table 6 is implicitly scoped to a single primary SA and does not have an explicit relationship in that table. An entity SHOULD remove any RX Prekey when the wall-clock time advances past the end of its validity time interval.¶

The information in Table 7 is implicitly scoped to a single primary SA and does not have an explicit relationship in that table. An entity SHOULD remove any TX Prekey when the wall-clock time advances past the end of its validity time interval.¶

3.4. Secondary Security Associations

Each secondary SA allows SAFE entities to provide key material and associated policy configuration to a BPSec entity on the same BP node. The state of each secondary SA known to the local entity has logical columns as indicated in Table 8.¶

Each endpoint selector item functions as a filter for the BP Agent to determine to which bundles the SA applies. The order in which endpoint selectors and other filters are applied to filter bundles for security processing is an implementation matter and can be optimized to, for example, process the less expensive checks first to reduce the average expense of matching. An implementation is also free to perform additional indexing of endpoint selectors across multiple SAs to reduce total processing expense.¶

Each key use option contains fields necessary to restrict when and how the key can be used for BPSec security operations. The fields of each item roughly correspond with a COSE Key from Section 7 of [RFC9052] and an implementation can choose to use a COSE Key representation if that is convenient.¶

4.1. Activity Sequencing

The contents of a SAFE message allow it to be correlated to a specific activity sequence and an individual step within that sequence (see Section 4.2 for details). All steps are numbered starting with zero at the initiator of an activity. The sending of a step number greater than zero is also used to acknowledge receipt and processing of the message with its preceding step number. The final acknowledgement of an activity is sent without a corresponding data payload in order to indicate that it is the end of the sequence.¶

Because SAFE allows messages to be aggregated into an PDU, this also enables explicit pipelining of multiple activities over a sequence of PDUs. It is an implementation matter to determine when to aggregate messages but the patterns defined in Section 7 make use of aggregation.¶

An example of this pipelining is shown in Figure 9, which depicts a series of PDUs sent in opposite direction between two peers "A" and "B". An Initial Authentication (IA) is the first activity (initiated by "A"), followed by a Capability Indication (CI) activity (initiated by "B"), and finally a pair of SA Creation (SC) activities (initiated by "A").¶

  Entity A     A     A     A     A
         |     ^     |     ^     |
         v     |     v     |     v
  Entity B     B     B     B     B

 unsecured  | EDHOC security  | SAFE security

    PDU #1    #2    #3    #4    #5
         |     |     |     |     |
     (IA 0 --- 1 --- 2 --- 3)    |
         | (CI 0 --- 1 --- 2)    |
         |     | (SC 0 --- 1 --- 2)
         |     | (SC 0 --- 1 --- 2)

          =----- time ----->

As described in Section 4.4 and indicated in Figure 9, the IA step-0 message is always sent alone in a PDU and unsecured. After that IA step 1 through 3 messages use EDHOC session encryption to provide confidentiality with EDHOC EAD for SAFE message aggregation. All subsequent messaging occurs using SAFE ciphertext confidentiality with SAFE plaintext aggregation.¶

4.2. Message Structure

Each encoded SAFE message SHOULD use CBOR core deterministic encoding requirements from Section 4.2.1 of [RFC8949]. Each SAFE message SHALL consist of a CBOR sequence containing the following items.¶

Activity Index:

This item is an unsigned integer used to correlate multiple messages associated with the same activity. Each activity SHALL be assigned a unique activity index when it is started by the initiator. A default algorithm to assign an activity index is to start at index zero for the first activity of a conversation and increment by one for each subsequent activity in that conversation.¶

Activity Step:

This item is an unsigned integer used to distinguish messages for each step of an activity. The activity step value SHALL be limited to the inclusive range 0 to 65535. It is expected that most activity types will only involve two or three steps with a final acknowledgement, so the meaningful range of this value is much lower than the required range.¶

Activity Type:

This item is a signed integer used to distinguish the purpose of the associated activity and of the data payload which follows. The activity type value SHALL be limited to the inclusive range -32768 to 32767. As defined in Section 12.3, positive values are for well-known activities, zero is reserved for the IA pseudo-activity (Section 5.1), and negative values are reserved for experimental or private use.¶

Data Payload:

This item is either a CBOR map or a byte string, used to contain data specific to the logical step in the activity corresponding to the containing message.¶

The combination of Activity Index and Activity Step SHALL uniquely identify a message in an activity sequence independently of the type of activity being performed.¶

The activity index SHALL be unique per initiator and transport conversation (e.g., unordered pair of source and destination EID). The first activity index for a conversation SHALL be zero, and each subsequent activity initiated by a peer SHALL increment the activity index by one.¶

The first step of an activity SHALL be zero, and each subsequent step SHALL increment by one. This means that the initiator of an activity can be identified implicitly because it will only send messages with an even step number and will only receive messages with an odd step number.¶

The last message of an activity sequence SHALL NOT contain either an activity type or a data payload. That last message is purely to acknowledge the message from the previous step and conclude the activity.¶

This structure is indicated by the following CDDL for the general SAFE message structure and its data item payload.¶

safe-msg-bstr = bstr .cborseq safe-msg

safe-msg = $safe-msg .within safe-msg-struct
safe-msg-struct = [
    msg-ident,
    ? (
        act-type: int16,
        data-map
    )
]

; Unique identifier for a single message (one step of one activity)
msg-ident = (
    act-idx: uint,
    act-step: uint,
)

; activity-type-specific data
; non-negative labels are well-known
; negative labels are private use
data-map = {
    * label => value,
}
; Generic map label
label = int16
; Generic map value
value = any

; Signed integer that fits in 16-bit two's complement form
int16 = -32768 .. 32767

4.3. States, Deduplication, and Retransmission

As described in Section 3.2, the state kept by each entity about an activity includes the step of the message last sent by the entity (LTX) and the step of the message last received from the peer entity (LRX). Based on these two step states, each entity can determine how to make progress¶

An example of this logic is shown in Figure 10. The state notation of {LTX,LRX} indicates the LTX and LRX steps respectively and negative values are used as a placeholder for an invalid/absent step number. In that diagram, if a state transition has a specific trigger condition it is indicated by square bracket text.¶

             Initiator                         Responder
        +-----------------+               +-----------------+
        |                 |               |                 |
        | {-1,-1} Start   |               | {-1,-1} Start   |
        |                 |     Step 0    |                 |
        +--------+--------+    Message    +--------+--------+
      Re-TX      |            ident+data     [RX 0]|
     +--------+  | TX 0    ~~~~~~~~~~~~~~>         |
     |        v  v                                 v
     |  +-----------------+               +-----------------+
     |  |                 |               |                 |
     +--+ { 0,-1} Wait    |               | {-1, 0} Process |
 [timer]|                 |     Step 1    |                 |
        +--------+--------+    Message    +--------+--------+
                 |[RX 1]      ident+data           |         Re-TX
                 |         <~~~~~~~~~~~~~~    TX 1 |  +--------+
                 v                                 v  v        |
        +-----------------+               +-----------------+  |
        |                 |               |                 |  |
        | { 0, 1} Process |               | { 1, 0} Wait    +--+
        |                 |     Step 2    |                 |[timer]
        +--------+--------+    Message    +--------+--------+[Re-RX]
      Re-TX      |              ident        [RX 2]|
     +--------+  | TX 2    ~~~~~~~~~~~~~~>         |
     |        v  v                                 v
     |  +-----------------+               +-----------------+
     |  |                 |               |                 |
     +--+ { 2, 1} Finished|               | { 1, 2} Finished|
 [Re-RX]|                 |               |                 |
        +--------+--------+               +--------+--------+
                 |[timer]                   [timer]|
                 v                                 v
        +-----------------+               +-----------------+
        |                 |               |                 |
        | {-1,-1} Removed |               | {-1,-1} Removed |
        |                 |               |                 |
        +-----------------+               +-----------------+

Based on an existing activity state (Section 3.2) when the last LTX step is less than the LRX step, or when the initiator starts the activity, or an activity-associated retransmission timer expires, the entity SHALL perform the following:¶

1. Compute the next step number as either: one more than the LRX step, if it is valid, or step zero if the initiator has just started the activity.¶

2. If the next step is within the number of steps for this activity type, generate type-specific data items based on the activity type and next step.¶

   Otherwise, only the message identity is present and no activity type or data items are needed.¶

3. Encode and store an encoded SAFE message.¶
4. Send the SAFE message within a PDU (possibly combining with other messages to the same peer entity).¶
5. Update the LTX step to correspond with the sent message.¶

6. If either the LTX or LRX step are beyond the number of steps for this activity type, the activity is in the finished state.¶

   Otherwise, begin a retransmission timer associated to the activity index with a duration taken from the expected round-trip time between the peer node plus some optional additional margin. It is an implementation matter to determine the specific margin added to the expected round-trip duration.¶

Upon receiving a SAFE message from a peer, an entity SHALL perform the following:¶

1. Decode at least the message identity (to be able to look up the activity state).¶
2. Determine which role this entity is performing by inspecting the step number: even steps are sent by the initiator and odd steps are sent by the responder.¶
3. Use the peer EID and activity index to look up the specific activity state (Section 3.2) corresponding to the message.¶
4. If the received message has a step less than or equal to the LRX of the activity state, it is ignored and this procedure is terminated.¶
5. If present, decode and process the activity type and type-specific data items.¶
6. Update the LRX step to correspond with the received message.¶
7. If either the LTX or LRX step are beyond the number of steps for this activity type, the activity is in the finished state.¶

Error indication and handling is generally accomplished by terminating an activity early, indicating error conditions within data item(s) specific to the activity type, and possibly the initiator of the terminated activity attempting a new activity of that type with options adjusted based on error feedback. When an error is indicated on an activity it SHALL be considered finished regardless of the step in which the error was indicated.¶

4.4. Message Aggregation

The message aggregation sub-layer allows one or more encoded SAFE messages (as opaque byte strings) to be concatenated together, along with optional padding, into a single plaintext as defined in Figure 11. The entire SAFE plaintext SHALL be a CBOR sequence. Each SAFE message SHALL be represented as a CBOR byte string item containing a single encoded SAFE message as defined in Section 4.2.¶

If present, the padding SHALL be the last item in the plaintext sequence. The padding SHALL be identified by CBOR tag 55799, indicating "Self-described CBOR" as defined in Section 3.4.6 of [RFC8949]. This tag is arbitrary and provides no additional semantics, it is solely used to distinguish between SAFE message byte strings in the plaintext. It is an implementation matter to determine when and how much padding is added to any SAFE plaintext. A receiver of SAFE plaintext SHALL ignore any padding.¶

; A sequence of encoded-message bstr with optional tagged padding
safe-pdu-plaintext = (+ safe-msg-bstr, ? safe-padding)
safe-padding = #6.55799(bstr)

; TODO this needs to be redefined and used as part of SAFE confidentiality
safe-pdu-aad = (
  rx-sai: safe-sai
)

4.5. Packetization

Because SAFE is used to provide BPSec key material, the security properties of a SAFE bundle are more complex than other BP flows might be. For example, the bundles carrying Initialization messages need to be transported as plaintext payload (with intrinsic EDHOC protections) while other SAFE bundles need to be protected by the keys from a primary SA (negotiated as part of the EDHOC sequence).¶

The structure of a SAFE PDU is a CBOR sequence of the SAFE version number followed by header items and then payload items. The protocol in this document SHALL be identified by version number 1. The version specific header defined in this document SHALL be the following:¶

Partial IV:

A partial IV byte string or the null value to indicate EDHOC security.¶

Key Identifier:

A key identifier within the primary SA or the null value to indicate EDHOC security.¶

Receiver SAI:

A receiver SAI byte string or integer (based on EDHOC compressed byte string encoding) or the true value.¶

When the Partial IV and Key Identifier are both null, the payload SHALL be one of the EDHOC messages defined in [RFC9528] and handled in accordance with Section 5.1 and Section 9.1.1. When the Receiver SAI is true, the payload SHALL be a Message 1 as defined in Section 5.2 of [RFC9528]. All other Receiver SAI values SHALL be treated as a connection identifier, encoded in accordance with Section 3.3.2 of [RFC9528], used to correlate with an existing EDHOC session.¶

When the Partial IV and the Key Identifier are not null, the payload SHALL be a SAFE ciphertext and handled in accordance with Section 9.1.2. In this case, Receiver SAI values SHALL be decoded as and treated as a Security Association Identifier (SAI) used to correlate with the Local SAI of a Primary SA (see Table 3) on the receiving entity.¶

Any other combinations of header values SHALL be treated as invalid and discarded by a receiver.¶

These cases are indicated by the following CDDL for the SAFE bundle PDU sequence.¶

; Encoded to PDU as CBOR sequence without array head
safe-pdu-seq = [
    version: 1,
    ; PDU variants follow the same structure with unique prefix items
    safe-pdu-edhoc // safe-pdu-confidential,
]

safe-pdu-edhoc //= (
    partial-iv: null,
    psa-kid: null,
    rx-sai: true,
    ; Group message_1 from RFC 9528
    message_1
)
safe-pdu-edhoc //= (
    partial-iv: null,
    psa-kid: null,
    rx-sai: safe-sai,
    edhoc_234 // error
)
; Equivalent to (message_2 // message_3 // message_4) from RFC 9528
; Encoded SAFE messages can be present as critical EAD items
edhoc_234 = bstr

safe-pdu-confidential //= (
    partial-iv: bstr,
    psa-kid: safe-kid,
    rx-sai: safe-sai,
    ; Ciphertext data corresponding to `safe-pdu-plaintext` rule
    ciphertext: bstr
)

Within restrictions defined for each message type, multiple messages MAY be combined into a single PDU, as either EDHOC EAD (Section 5.1) or SAFE plaintext (Section 4.4). Due to the logic of the IA activity sequencing, only one EDHOC session can make progress between two endpoints at any time so there is no concept of a full EDHOC PDU embedded within an EAD item, only individual messages.¶

4.6. PDU Transport

Each SAFE PDU is handled as an application data unit (ADU) of a BPv7 bundle, referred to as a "SAFE bundle" in this document. Additional constraints, controllability, and visibility on transport parameters are defined in the following subsection.¶

Both the source and destination EID, defined in Section 4.3.1 of [RFC9171], for a SAFE bundle SHALL be singleton. The source EID for SAFE bundles SHALL NOT be a null EID. Each endpoint for SAFE messaging needs to be an identified singleton. The bundle source and destination EID for received bundles SHALL be exposed to the SAFE entity in order to support message exchange sequencing.¶

When using the IPN scheme, the EIDs used as source and/or destination SHOULD use the well-known service number defined in Section 12.1. SAFE entities can use other schemes and service numbers, but such configuration is an implementation and deployment matter.¶

The bundle creation timestamp (both DTN time and sequence number), defined in Timestamp Section 4.3.1 of [RFC9171], for received bundles SHALL be exposed to the SAFE entity to allow it to de-duplicate and order received SAFE bundles.¶

5.1. Initial Authentication (IA)

This activity is used to establish an initial shared secret between two SAFE endpoints which don't already have a usable SA, or when re-authentication is deemed necessary by either side of an existing SA.¶

Because this is the initializing activity for all other SAFE interactions, and occurs outside of any pre-existing SA, it does not follow the same message structure as other SAFE activities but it does use the same local progress bookkeeping and retransmission logic (from Section 4.3). The retransmission logic and the BP transport of Section 4 satisfies the EDHOC requirements of Section 3.4 of [RFC9528].¶

Even though the IA activity does not follow the same messaging structure, it does have an activity identifier allocated to it in Table 30 to allow its state to be tracked in accordance with Section 3.2. The IA activity SHALL be identified by activity type 0.¶

Only one instance of this activity SHOULD be in progress at any time. The data of each PDU for the IA activity SHALL contain an EDHOC message as defined in Section 5 of [RFC9528].¶

The sequence of steps and their data for this activity are the following:¶

• Step 0: The PDU payload is an EDHOC Message 1 sequence.¶
• Step 1: The PDU payload is an EDHOC Message 2 byte string.¶
• Step 2: The PDU payload is an EDHOC Message 3 byte string.¶
• Step 3: The PDU payload is an EDHOC Message 4 byte string.¶

An indication of failure in the activity is provided by an EDHOC error CBOR sequence in place of the normal EDHOC message. SAFE entities SHALL use EDHOC errors in accordance with Section 6 of [RFC9528].¶

During transport, PI PDUs SHALL NOT be the target of a BPSec confidentiality operation between the participating (source and destination) nodes. The use of application-level confidentiality ensures the security of information exchanged via this PDU. There is no restriction on any intermediate security handling of SAFE PDUs between the participating entities.¶

The CDDL corresponding to this activity type are the first two variations of safe-pdu-seq from Section 4.5. Additionally, the EAD payload of the EDHOC messages are extended to be able to confidentially carry encoded SAFE messages during the IA activity. Any number of EAD items of label -TBA5 and value matching the safe-msg-bstr rule (defined in Section 4.2) MAY be present in EDHOC lists EAD_2, EAD_3, and EAD_4. EAD items of label TBA5 SHALL NOT be present in EAD_1, which is transported as plaintext. When present, all SAFE EAD items SHALL use the negative label to indicate that the item is critical and cannot be ignored by the receiver.¶

Upon the first reception or transmission of IA step 2 (i.e., EDHOC message_3), the entity SHALL create a primary SA based on the data derived in Section 8.1. Each entity SHALL populate the primary SA with one TX Content Key and one RX Content Key each with a KID of the empty byte string as defined in Section 8.4. what about validity time of CKs? Any time after the first reception or transmission of IA step 2, either entity MAY initiate other activities which refer to the new SA. Before that step has occurred the primary SA is still being negotiated and has not yet been created.¶

5.2. Capability Indication (CI)

This activity allows each entity to indicate its SAFE-related capabilities to its peer. The Capability Indication (CI) activity SHALL be identified by activity type 1.¶

If the receiver of CI step 0 or step 1 does not find its content acceptable it SHALL reply with an error indication, not create any associated primary SA, and abort the parent IA activity. If a CI step 1 or 2 contains an error indication, the receiver SHALL not create any associated primary SA, and abort the parent IA activity.¶

The sequence of steps and their data for this activity are the following:¶

• Step 0: The payload is a map containing data items as defined below. Each item expresses a capability of the initiator entity.¶
• Step 1: The payload is a map containing data items as defined below. Each item expresses a capability of the responder entity.¶
• Step 2: Either no payload, indicating pure acknowledgement, or a map containing a single error item.¶

ci-data = { * $$ci-data } .within data-map

$$ci-data //= (1: concur-act-limit)
$$ci-data //= (2: eid-scheme-list)
$$ci-data //= (3: bpsec-ctxid-list)

$$ci-data //= (10: key-depth-range)
$$ci-data //= (11: key-depth-range)
$$ci-data //= (12: key-depth-range)
$$ci-data //= (13: key-depth-range)

It is not until reception of a peer's CI information that later activities can be initiated with the expectation that they will succeed. Any time after the first reception of CI step 0 or 1, the receiving entity MAY initiate other activities which rely on the capabilities expressed in the CI data items.¶

5.3. Event Notification (EN)

This activity is used by the initiator to inform the peer entity of an event which affects the entire primary SA. The Event Notification (EN) activity SHALL be identified by activity type 2.¶

The sequence of steps and their data for this activity are the following:¶

• Step 0: The payload is a map containing data items as defined below.¶
• Step 1: No payload, message is acknowledgement.¶

en-data = {* $$en-data } .within data-map

$$en-data //= (1: en-cause)
en-cause = [msg-ident]

5.4. SA Creation (SC)

This activity is used to create a new SA from within the context of an existing primary SA. The SA Creation (SC) activity SHALL be identified by activity type 3.¶

The sequence of steps and their data for this activity are the following:¶

• Step 0: The payload is a map containing data items as defined below. Some items (notably ESI, ESR, and KUS) MAY contain multiple proposals to allow the responder a selection.¶
• Step 1: The payload is a map containing data items as defined below. All items SHALL contain only a single proposal each.¶
• Step 2: No payload, message is acknowledgement.¶

The responder items with proposals SHALL be a logical subset of the initiator-provided proposals. The Secondary SA SHALL be configured to use a logical intersection between the items provided by the initiator and by the responder. For some cases of EID patterns, the intersection can be derived as a single pattern generated from the initiator and responder options. But for more complex cases, the intersection needs to be represented as a logical AND between the two separate patterns.¶

sc-data = {* $$sc-data } .within data-map

; Error codes from the responder
$$sc-data //= (0: safe-ete)
; SAI for the sender
$$sc-data //= (1: safe-sai)

; Initiator side endpoint selectors
$$sc-data //= (6: safe-esx)
; Responder side endpoint selectors
$$sc-data //= (7: safe-esx)
; Time limit for the SA
$$sc-data //= (8: safe-nti)

; BPSec Context and its options for how to use the content keys
$$sc-data //= (4: safe-sos)
$$sc-data //= (5: safe-kus)

$$ci-data //= (10: key-depth-range)
$$ci-data //= (11: key-depth-range)
$$ci-data //= (12: key-depth-range)
$$ci-data //= (13: key-depth-range)

Upon the first reception or transmission of SC step 1, the entity SHALL create a secondary SA based on the data derived in Section 8.1 with no initial content keys or prekeys. Any time after the first reception or transmission of SC step 1, either entity MAY initiate other activities which refer to the new SA. Before that step has occurred the secondary SA is still being negotiated and has not yet been created.¶

5.5. SA Teardown (ST)

This activity is used to negotiate removal of an established SA from both entities. Either peer can initiate this activity for any reason at any time after the SA is created. The SA Teardown (ST) activity SHALL be identified by activity type 5.¶

The sequence of steps and their data for this activity are the following:¶

• Step 0: The payload is a map containing data items as defined below.¶
• Step 1: The payload is a map containing data items as defined below.¶
• Step 2: No payload, message is acknowledgement.¶

st-data = {* $$st-data } .within data-map

; Error codes from the responder
$$st-data //= (0: safe-ete)
; SAI for the sender
$$st-data //= (1: safe-sai / true)

Upon the first reception or transmission of ST step 1, the entity SHALL remove the referenced SA from its associated information bases. Any time after the first reception or transmission of ST step 1, either entity SHALL NOT refer to the removed SA from any other activities.¶

5.6. CK Prekey (CP)

This activity is used to preemptively share a one-time-use public key which can be used to add forward secrecy to later-derived content keys in the CK Creation (CC) activity. The recipient of the CP activity will be the initiator of the later CC activity. The SA Prekey (SP) activity SHALL be identified by activity type 5.¶

The sequence of steps and their data for this activity are the following:¶

• Step 0: The payload is a map containing data items as defined below.¶
• Step 2: No payload, message is acknowledgement.¶

cp-data = {* $$cp-data } .within data-map

; Identifiers for the responder
$$cp-data //= (1: safe-sai)
$$cp-data //= (2: safe-kid)

$$cp-data //= (3: safe-nti)
$$cp-data //= (4: safe-pks)

Upon the first reception of CP step 0, the entity SHALL correlate the Local SAI of a Primary SA or Secondary SA and record the prekey information within TX Prekey store of the SA. Any time after the first reception of CP step 0, the entity MAY initiate CK Creation (CC) activities which refer to the new prekey by its KID.¶

5.7. CK Creation (CC)

This activity is used to establish a new set of derived key (and possibly other) material within an existing SA without changing the other parameters of the SA (e.g., algorithm choice or endpoint selectors). The CK Creation (CC) activity SHALL be identified by activity type 6.¶

The sequence of steps and their data for this activity are the following:¶

• Step 0: The payload is a map containing data items as defined below.¶
• Step 2: No payload, message is acknowledgement.¶

cc-data = {* $$cc-data } .within data-map

; Identity of the new CK from the initiator
$$cc-data //= (1: safe-sai)
$$cc-data //= (2: safe-kid)

; Optional PRF parameters
$$cc-data //= (10: safe-kid)
$$cc-data //= (11: safe-arn)

Upon the first reception or transmission of CC step 0, the entity SHALL correlate the responder SAI of a Primary SA or Secondary SA and create a new content key within it based on the derived secrets defined in Section 8.4 or Section 8.5 respectively. Any time after the first reception or transmission of CC step 0, either entity MAY initiate CK Discard (CD) or CK Reject (CR) activities which refer to the new content key by its KID.¶

5.8. CK Discard (CD)

This activity is used to indicate that an earlier content key has been discarded from its TX side owner and will no longer be used for any data plane security. The CK Discard (CD) activity SHALL be identified by activity type 7.¶

It is an implementation matter to determine when to initiate a CK Discard activity. The CK Discard SHOULD NOT be initiated after the validity time interval of the content key has expired, as it will not serve any purpose to the responder.¶

The sequence of steps and their data for this activity are the following:¶

• Step 0: The payload is a map containing data items as defined below.¶
• Step 1: No payload, message is acknowledgement.¶

cd-data = {* $$cd-data } .within data-map

; Identity of the CK from the initiator
$$cd-data //= (1: safe-sai)
$$cd-data //= (2: safe-kid)

Upon the first transmission of CD step 0, the entity SHALL correlate the contained SAI with the peer SAI of a Primary SA or Secondary SA and correlate the contained KID with the KID of one of the TX Content Keys and remove that TX content key. Upon the first reception of CD step 0, the entity SHALL correlate the contained SAI with the peer SAI of a Primary SA or Secondary SA and correlate the contained KID with the KID of one of the RX Content Keys and remove that RX content key. Any time after the first reception or transmission of CD step 0, either entity SHALL NOT refer to the removed content key from any other activities. After transmission of CD step 0, the removed content key SHALL NOT be used for any later SAFE or data plane security.¶

5.9. CK Reject (CR)

This activity is used to indicate that an earlier content key has been rejected from its RX side and will no longer be used for any data plane security. The CK Reject (CR) activity SHALL be identified by activity type 8.¶

It is an implementation matter to determine when to initiate a CK Reject activity. The CK Reject SHOULD NOT be initiated after the validity time interval of the content key has expired, as it will not serve any purpose to the responder.¶

The sequence of steps and their data for this activity are the following:¶

• Step 0: The payload is a map containing data items as defined below.¶
• Step 1: No payload, message is acknowledgement.¶

cr-data = {* $$cr-data } .within data-map

; Identity of the CK from the initiator
$$cr-data //= (1: safe-sai)
$$cr-data //= (2: safe-kid)

Upon the first transmission of CR step 0, the entity SHALL correlate the contained SAI with the peer SAI of a Primary SA or Secondary SA and correlate the contained KID with the KID of one of the RX Content Keys and remove that content key. Upon the first reception of CR step 0, the entity SHALL correlate the contained SAI with the peer SAI of a Primary SA or Secondary SA and correlate the contained KID with the KID of one of the TX Content Keys and remove that content key. Any time after the first reception or transmission of CR step 0, either entity SHALL NOT refer to the removed content key from any other activities. After reception of CR step 0, the removed content key SHALL NOT be used for any later SAFE or data plane security.¶

6.1. Error Type Enumeration (ETE)

The Error Type Enumeration (ETE) data item is used by its sender to signal a failure to process a message or make progress in an activity. The ETE value SHALL be an integer limited to the inclusive range -32768 to 32767.¶

These values are used in many activities to indicate a failure in decoding, processing, or consistency of received message contents. Well-known error values are non-negative and registered in Section 12.3. Private and experimental use error values are negative and not registered.¶

safe-ete = [+ safe-error]
safe-error = int16

6.2. Concurrent Activity Support (CAS)

This data item indicates how many concurrent (pipelined) SAFE activities the sender of the item supports. The minimum number of concurrent activities supported SHALL be 2.¶

This is necessary in order to enable the processing of Capability Indication (CI) containing this data item during the Initial Authentication (IA) messaging. The maximum number of concurrent activities supported SHALL be 1024. This is an arbitrary upper bound not expected to be encountered during normal operations.¶

An attempt by a peer to send messages associated with more than this limit¶

concur-act-limit = 2 .. 1024

6.3. EID Scheme Support (ESS)

This data item indicates which EID schemes the sender of the item supports. Schemes are identified by the code points from the "Bundle Protocol URI Scheme Types" registry at [IANA-BUNDLE], which includes a block reserved for private-use. Expressing support for an EID scheme indicates that the node can handle EIDs of that scheme and EID Patterns with scheme-specific parts.¶

eid-scheme-list = [+ eid-scheme]
; Unrestricted per RFC 9171
eid-scheme = uint

6.4. BPSec Context Support (BCS)

This data item indicates which BPSec contexts the sender of the data item supports. Schemes are identified by the code points from the "BPSec Security Context Identifiers" registry at [IANA-BUNDLE], which includes a block of negative values reserved for private-use. Expressing support for a security context indicates that the node can handle sourcing, verifying, and accepting security blocks using that context.¶

bpsec-ctxid-list = [+ bpsec-ctxid]
; Restricted domain per RFC 9172
bpsec-ctxid = -32768 .. 32767

6.5. Key Depth Range (KDR)

This data item indicates a range of valid depth of a key store in the sending entity. The value is an array containing two items: a minimum valid depth as a uint and a maximum valid depth as a uint. The minimum depth SHALL be less than or equal to the maximum depth. Specific uses of this data item can further restrict the valid minimum or maximum.¶

key-depth-range = [
  min: uint,
  max: uint
]

6.6. Security Association Identifier (SAI)

The Security Association Identifier (SAI) data item is used by both sides of an SA to uniquely identify the SA within each entity. This means that a single SA has two SAIs used to identify it, one from each entity.¶

An SAI SHALL be treated as an opaque byte string as its internal representation and comparison logic. An SAI SHALL be limited to a length between 0 and 16 bytes inclusive. This length allows a Universally Unique IDentifier (UUID) [RFC9562] to be used as an SAI. An SAI SHALL have the same compressed encoding rules as EDHOC connection identifiers as defined in Section 3.3.2 of [RFC9528].¶

safe-sai = (bstr .size (0..16)) / (-24..23)

6.7. Key Identifier (KID)

The Key Identifier (KID) data item is used by both sides of an SA to uniquely identify a shared content key or prekey within each entity. All KIDs are guaranteed unique within the parent primary SA context, but each entity is able to reuse KID values across different primary SAs. Each content key has a single KID defined by the entity which initiated the creation of the symmetric key, and each content prekey has a single KID defined by the entity which holds the associated private key.¶

A KID SHALL be treated as an opaque byte string as its internal representation and comparison logic. A KID SHALL be limited to a length between 0 and 16 bytes inclusive. This length allows a UUID [RFC9562] to be used as an KID. A KID SHALL have the same compressed encoding rules as EDHOC connection identifiers as defined in Section 3.3.2 of [RFC9528].¶

safe-kid = (bstr .size (0..16)) / (-24..23)

6.8. Public Key Structure (PKS)

This data item indicates a public key from sender to enable forward secrecy during a later CK Create activity. The algorithm and parameters related to key exchange or encapsulation are taken from the EDHOC cipher suite negotiated during initial authentication.¶

safe-pks = COSE_Key  ; from [RFC 9052]

6.9. Additional Random Nonce (ARN)

This data item provides a random nonce value from the sender to add entropy into the PRF used during SA Creation (Section 5.4) and CK Creation (Section 5.7) to generate content key data. The data value SHALL be a byte string with a size in the inclusive range 1 to 256 bytes.¶

safe-arn = bstr .size (1..256)

6.10. Security Mode Selector (SMS)

This data item controls how the secondary SA is used in the BP data plane by the BPSec entity in each participating node. This data value SHALL be an integer limited to the inclusive range -32768 to 32767.¶

Based on the discussion in Section 1.2 this document defines two modes: end-to-end (1) and transport (2). The behavior of these modes is defined in Section 9.2. Future specifications can add additional mode code points with different behavior.¶

safe-sms = secondary-sa-mode .within int16
secondary-sa-mode = &(
    end-to-end: 1,
    transport: 2,
)

6.11. Node Time Interval (NTI)

This data item filters on the current DTN time of the node hosting the SAFE entity. The type is used to limit the validity time of the associated SA, but requires synchronization of time between the two peers to perform properly. The start time can be the current time to allow immediate use of the SA or can be in the future to pre-establish an SA meant to be used later on. An entity can use NTI in multiple SCs, possibly using concurrent SC activities, to establish a chain of SAs each spanning a small time interval that together spans a large time interval.¶

The NTI value SHALL consist of a start time and an end time. The SA established with an NTI value SHALL be valid at an after the start time (inclusive), and only before the end time (exclusive).¶

relocate this to secondary SA info section? Multiple SAs between the same two peers with the same mode and endpoint selectors MAY have validity NTIs which overlap in time. In that case, it is an implementation matter to choose which SA to use for securing traffic. prefer lexicographic lower SAI?¶

; Using DTN time as reported by the local BP node
safe-nti = [
    begin: dtn-time,
    end: dtn-time
]

6.12. Endpoint Selectors (ESx)

This data item is used to determine which individual bundles will correlate with a secondary SA by comparing their source and destination EIDs to patterns. There is a separate endpoint selector applied to the initiator and responder side of a secondary SA, where each side selects on the source EID for traffic being forwarded from that node and destination EID for traffic being received by that node.¶

This selector filters on the Source or Destination of the bundle contained in its primary block (see Section 4.3.1 of [RFC9171]). The pattern can, but doesn't need to, include the EIDs from the node to which it applies (see Section 1.2).¶

The value of this data item consists of one or more EID Pattern in accordance with [I-D.ietf-dtn-eid-pattern], as indicated by the following CDDL. When multiple patterns are present they each represent an alternate proposal provided by the initiator and chosen by the responder of an activity.¶

safe-esx = eid-selectors .within safe-proposals
eid-selectors = embed-eid-pattern / [+ embed-eid-pattern]

6.13. Security Operation Selectors (SOS)

This data item controls how the node of each SAFE endpoint applies BPSec security operations to traffic selected for handling by the secondary SA.¶

The SOS value SHALL be an array with the following items.¶

1. A list of target block types to which the security will be applied. Block type zero SHALL be used to refer to the primary block.¶
2. The type of security service being sourced by the forwarding entity and accepted by the receiving entity. This value is either integrity (1) or confidentiality (2), as defined in [RFC9172].¶

safe-sos = [
    target-block-types: [+ bpv7-block-type],
    service: bpsec-service,
]
; Type consistent with RFC 9171
bpv7-block-type = uint
; Services available in RFC 9172
bpsec-service = &(
    integrity: 1,
    confidentiality: 2,
)

6.14. Key Use Selectors (KUS)

This data item is used to negotiate the purpose(s) for which an SA-derived symmetric key can be used by each side of the SA.¶

The KUS value is an array with the following items.¶

1. A single BPSec Context Identifier value in accordance with the registry in [IANA-BUNDLE].¶
2. One or more maps of context-specific options, each representing an alternate proposal provided by the initiator and chosen by the responder of an activity. The interpretation of these options is specific to each BPSec Context ID. The initial set of supported contexts is defined in Section 9.¶

safe-kus = $safe-kus .within safe-kus-struct
safe-kus-struct = [
    ctxid: bpsec-ctxid,
    options: safe-proposals
]

Some examples of what KUS options can be defined by each Context binding are: a specific algorithm identifier or an choice of additional authenticated data (AAD) outside the security target block.¶

7.1. Concurrent Activities

The packetization form defined in Section 4 allows multiple messages to be combined into a single ADU but this behavior is limited by support for the receiving entity, as defined and communicated in the Concurrent Activity Support (CAS) data item.¶

The pairwise CAS limit is a hard upper bound on in-progress activities between pairs of entities, defined as the minimum of the local CAS limit and the CAS limit received from a peer entity. An entity SHALL NOT initiate any activity which would cause the total number of in-progress activities to exceed the pairwise CAS limit with a peer entity. An entity MAY ignore any messages from a peer which would cause the total number of in-progress activities to exceed its own CAS limit.¶

Each entity needs to leave some margin within the pairwise CAS limit for its peer to initiate new activities. An entity SHALL NOT initiate any activity which would cause the total number of in-progress activities for which it is the initiator to exceed the pairwise CAS limit with a peer entity less some CAS margin. An entity SHALL use a CAS margin of at least one. This always enables a peer to initiate one new activity. An entity SHOULD use a CAS margin that is some proportion to the CAS limit itself. An entity SHOULD allow a peer to initiate an activity which would exceed the local CAS margin. This allows entities to choose different CAS margin for their own reasons without negotiating.¶

Two examples of how this parameter affects activity sequencing is shown in Figure 13 for a large CAS limit and Figure 14 for a constraining limit of two. Note that when constrained, some activities can only begin with specific odd PDU numbers (from IA initiator) or even numbers (from the IA responder) so there are necessarily gaps between activities so less efficient use of the network.¶

The first example performs the following sequence of activities, using up to 7 concurrent activities:¶

1. IA to authenticate, initiated by Entity A.¶
2. Early CI to exchange capabilities of each entity before SAs are established.¶
3. One secondary SA initiated by Entity B (in PDU #2), with two non-FS CKs created by Entity B (in PDU #4) and two by Entity A (in PDU #5).¶
4. Two secondary SAs initiated by Entity A (in PDU #3), each with one non-FS CK created by Entity A (in PDU #5) and one by Entity B (in PDU #6).¶

PDU #1    #2    #3    #4    #5    #6    #7
     |     |     |     |     |     |     |
 (IA 0 --- 1 --- 2 --- 3)    |     |     |
     | (CI 0 --- 1 --- 2)    |     |     |
     | (SC 0 --- 1 --- 2)    |     |     |
     |     | (SC 0 --- 1 --- 2)    |     |
     |     | (SC 0 --- 1 --- 2)    |     |
     |     |     | (CC 0 --- 1)    |     |
     |     |     | (CC 0 --- 1)    |     |
     |     |     |     | (CC 0 --- 1)    |
     |     |     |     | (CC 0 --- 1)    |
     |     |     |     | (CC 0 --- 1)    |
     |     |     |     |     | (CC 0 --- 1)

          =----- time ----->

The second example performs the same sequence, limited to 3 concurrent activities (no more than 2 initiated by each side):¶

1. IA to authenticate, initiated by Entity A.¶
2. CI to exchange capabilities of each entity before SAs are established.¶
3. One secondary SA initiated by Entity B (in PDU #2), with two CKs created by Entity B (in PDU #8) and two by Entity A (in PDU #5 and #7).¶
4. Two secondary SAs initiated by Entity A (in PDU #5), each with one CK created by Entity A (in PDU #9) and one by Entity B (in PDU #10).¶

PDU #1    #2    #3    #4    #5    #6    #7    #8    #9    #10   #11
     |     |     |     |     |     |     |     |     |     |     |
 (IA 0 --- 1 --- 2 --- 3)(SC 0 --- 1 --- 2)(CC 0 --- 1)(CC 0 --- 1)
     | (CI 0 --- 1 --- 2)(SC 0 --- 1 --- 2)(CC 0 --- 1)
     | (SC 0 --- 1 --- 2)(CC 0 --- 1)(CC 0 --- 1)(CC 0 --- 1)

          =----- time ----->

7.2. Establishment Ordering

Regardless of how activities are aggregated into specific ADUs, the following requirements apply to ordering of activities related to a single primary SA. These build upon the per-activity constraints defined in Section 5 to define a required or preferred order of activities, specifically during primary SA establishment.¶

When no primary SA exists between two SAFE application endpoints, the first messaging between those applications SHALL be Initial Authentication (IA) used to establish an initial private channel and mutually authenticate each peer. After a primary SA exists, either side of the SA MAY choose to initialize a new primary SA and re-authenticate with its peer.¶

Only after step 0 of the IA activity has been received, the responder for the IA activity SHALL begin a Capability Indication (CI) activity. This CI activity MAY begin immediately upon sending of the IA step 1, before the IA initiator has been authenticated, or MAY wait until after the IA activity has completed step 2 and both peers are authenticated. It is an implementation matter to configure whether CI is allowed before mutual authentication.¶

After step 3 of the IA activity has been received, both peers have authenticated each other and established a primary SA configured with a single content key in each direction, each having indefinite validity time, and no content prekeys. Any additional content keys on the primary SA depend on CC activities by each peer to create those keys.¶

PDU #1    #2    #3    #4    #5    #6
     |     |     |     |     |     |
 (IA 0 --- 1 --- 2 --- 3)    |     |
     | (CI 0 --- 1 --- 2)    |     |
     |     |     |     |     |     |
                      PSA
                      SSA

          =----- time ----->

PDU #1    #2    #3    #4    #5    #6
     |     |     |     |     |     |
 (IA 0 --- 1 --- 2 --- 3)    |     |
     |     |     | (CI 0 --- 1 --- 2)
     |     |     |     |     |     |
                      PSA         SSA

          =----- time ----->

Only after step 0 of the CI activity has been received, the responder for the activity SHOULD begin any number of needed CK Creation (CC) activities for the primary SA SA Creation (SC) activities to establish secondary SAs. Only after step 1 of the CI activity has been received, the initiator for the activity SHOULD begin any number of needed CK Creation (CC) activities for the primary SA SA Creation (SC) activities to establish secondary SAs. The number of concurrent activities allowed to be started at each step is limited by the CAS limit for the receiving peer.¶

    +-----------+
    |   Start   |
    +-----+-----+
IA step 0 |
          |
  +-------v--------+
  |                |
  |  Initializing  <---.
  |                |   |
  +-------+---+----+   | IA step 1-2
IA step 3 |   |        |
          |   '--------`
          |
  +-------v--------+
  |                |
  |   Established  <---.
  |                |   | CK activities
  +-------+------+-+   | PK activities
ST step 0 |      |     | (optional)
          |      '-----`
    +-----v-----+
    | Half Down |
    +-----------+
ST step 1 |
    +-----v-----+
    |  Removed  |
    +-----------+

7.3. Content Key Upkeep

Initiating or responding to the creation of a new SA establishes an obligation by each entity to upkeep content keys in that SA. There are two extremes of strategy for keeping content keys replenished in each direction within an SA, described below. Each entity is in control of its own TX content keys and corresponding RX content keys of its peer, and is free to choose a strategy to do so without negotiation. Future extensions to SAFE can define new CI data items and SC data items that allow negotiating such behavior between peers.¶

Reactive Keying:

This strategy is to ensure that one TX content key has a validity time including the current wall-clock time. When that validity time is about to expire perform a CC activity to create a new one. This strategy uses fewer key store entries but requires a just-in-time interactivity to create new keys as needed.¶

Pre-planned Keying:

This strategy is to establish a backlog of current and future TX content keys, either out to a specific horizon of time or a specific depth of number. As the current keys expire, the backlog is added to to maintain the desired horizon or depth. This strategy avoids just-in-time behavior but requires more key store size.¶

7.4. Prekey Upkeep

Similar to the discussion in Section 7.3 entities which agree to use forward secrecy on some (or all) of their RX content keys need to upkeep RX content prekeys in that SA. Part of that is generating private prekey material locally and the other part is sending public prekey material to the peer entity.¶

8.1. Security Association PRK

Each primary and secondary SA is created with a unique SAI from each peer, so the pair of SAI values provides a unique context for deriving an SA-specific, stable PRK of fixed-length (based on the EDHOC cipher suite).¶

The EDHOC processes which generate the input PRK_Exporter causes that PRK to be bound to all of the transcript hash (TH) data from the EDHOC session, including the ephemeral keys used to establish that session. That EDHOC_Exporter is used once during each SA creation to derive a seed PRK for the entire SA. The PRK of each SA is then used to deterministically derive content keys under that specific SA.¶

Pseudocode used to explain this is shown in Figure 21, where the named parameters are:¶

The value TBA4:

The exporter label allocated to BP SAFE.¶

SAI_i and SAI_r:

The Security Association Identifier (SAI) from the initiator and responder respectively¶

hash_length:

The length of output size of the Hash Algorithm of the Primary SA.¶

PRK_SA = EDHOC_Exporter(TBA4, E(SAI_i) | E(SAI_r), hash_length)

8.2. Prekey Shared Secret

The prekey shared secret (PSS) process is used to produce additional key material (AKM) data to enable forward secrecy of derived values. The AKM is not assumed to be uniformly random, so it needs to use a KDF extraction function (with appropriate salt) to derive any PRK values. This is the exact same strategy and mechanism used by EDHOC itself for static DH authentication in Section 4.1.1 of [RFC9528].¶

When the prekey is an ECDH derivation key, the AKM_CK is the secret G_XY from the ECDH process. When the prekey is a KEM decapsulation key, the AKM_CK is the secret K from the KEM decapsulation process.¶

8.3. Content Key PRK

Each content key material is derived from a PRK which can either have forward secrecy or not, depending on a choice made by the initiator of the CK Create activity. Either the CK Create activity references an associated Prekey known to the responder, which is used to derive or decapsulate ephemeral additional key material (AKM) used for forward secrecy, or it does not reference a prekey and no forward secrecy is provided.¶

When no prekey is referenced during SA creation, the PRK_CK used is the associated PRK_SA value of the parent SA.¶

When a prekey is referenced during SA creation, the PRK_CK is extracted based on a chosen prekey as shown in Figure 22, where the named parameters are:¶

PRK_SA:

The parent SA PRK value.¶

KID_CK:

The KID of the to-be-created content key, unique within the parent SA key store, taken from a Key Identifier (KID) from the initiator.¶

KID_PK:

The KID of the referenced prekey, unique within the parent SA key store, taken from a Key Identifier (KID) from the initiator.¶

hash_length:

The length of output size of the Hash Algorithm of the Primary SA.¶

AKM_CK:

The prekey shared secret, as defined in Section 8.2¶

SALT_CK = SAFE_EXP(PRK_SA, E(KID_CK) | E(KID_PK), hash_length)
PRK_CK = SAFE_EXT(SALT_CK, AKM_CK)

8.4. Primary SA Content Keys

The primary SA content keys take the form of COSE key objects as defined in Section 7 of [RFC9052]. Because the acceptable algorithms are limited to AEAD encryption, the acceptable operations for each key in each entity are one of: encrypt (3), or decrypt (4).¶

When creating a new primary SA content key, the COSE key SHALL contain the following parameters.¶

kty (1):

The value Symmetric (4).¶

kid (2):

The KID byte string from the content key information, which may be the empty string.¶

alg (3):

The AEAD Algorithm of the primary SA.¶

key_ops (4):

Either encrypt (3) if this is a TX Content Key, or decrypt (4) if this is an RX Content Key¶

Base IV (5):

The BIV_SA1 value from Figure 23.¶

k (-1):

The SK_SA1 value from Figure 23.¶

Pseudocode used to explain this is shown in Figure 23, where the named parameters are:¶

KID:

The Key Identifier (KID) from the initiator as an encoded CBOR byte string.¶

ARN:

The Additional Random Nonce (ARN) from the initiator, or the empty byte string if no such data item was received, as an encoded CBOR byte string.¶

PRK_CK:

Either the PRK extracted based on the local prekey, if a prekey was referenced by the initiator, or the PRK from the Primary SA.¶

key_length:

The length of the encryption key for the AEAD Algorithm of the Primary SA.¶

iv_length:

The length of the initialization vector for the AEAD Algorithm of the Primary SA.¶

context_ck1 = E(KID) | E(ARN)

SK_SA1   = SAFE_EXP(PRK_CK, E(1) | context_ck1, key_length)
BIV_SA1 = SAFE_EXP(PRK_CK, E(2) | context_ck1, iv_length)

8.5. Secondary SA Content Keys

Additional output key material (OKM) specific to the BPSec security context being used is derived from the PRK_SA2 value with integer labels for different, security-context-specific purposes. It is part of the obligation of each BPSec key use to define what label values apply to key material needed by that context. An IANA registry for recording these labels is defined in Section 12.3.¶

Pseudocode used to explain this is shown in Figure 24, where the named parameters are:¶

ctxid:

The BPSec Context Identifier as an unsigned integer¶

context:

The BPSec-context-specific context byte string, which can be the empty byte string if not needed¶

length:

The length of output key material being derived¶

SAFE_OKM(ctxid, context, length)
  = SAFE_EXP(PRK_SA2, ctxid | context, length)

9.1. SAFE Confidentiality

Part of the purpose of establishing a primary SA with a peer is to derive an encryption key (with associated base IV) to enable SAFE message confidentiality in each direction. Similar to how EDHOC cryptographic functions make use of COSE primitives but not COSE message encodings, SAFE reuses COSE primitives for its own end-to-end security.¶

9.2. Common BPSec Operation

This section contains logic related to how the Security Mode Selector (SMS), Validity Time Interval, Endpoint Selectors, and Security Operation Selector (SOS) of the Secondary SA (as described in Section 3.4) inform the BPSec entity on both the Initiator and Responder nodes.¶

The SMS value determines at which of the BP Agent interaction points (see Figure 2) the SA is applicable with logic as follows.¶

1. When the SMS value is end-to-end (1), the node SHALL apply the SA policy at bundle transmission (from endpoint application) as source and at bundle delivery (to endpoint application) as acceptor.¶

   When the SMS value is transport (2), the node SHALL apply the SA policy at bundle forwarding (to CLA) as source and at bundle reception (from CLA) as acceptor.¶

2. At the source interaction point, the node SHALL only apply the SA policy when the current DTN time of the node is within the Validity Time Interval of the SA.¶

   At the acceptor interaction point, the node SHALL only apply the SA policy when the DTN time from the Timestamp of the Primary Block (see Section 4.3.1 of [RFC9171]) is within the Validity Time Interval of the SA.¶

3. At each interaction point, the node SHALL compare the Source and Destination EID of the Primary Block (as defined in Section 4.3.1 of [RFC9171]) of each bundle against one of the following.¶

   At the source interaction point, the Source EID is compared to the Local Endpoint Selectors field and the Destination EID is compared to the Peer Endpoint Selectors field.¶

   At the acceptor interaction point, the Source EID is compared to the Peer Endpoint Selectors field and the Destination EID is compared to the Local Endpoint Selectors field.¶

4. If the bundle has passed the above checks, the Security Operation Selector is used to determine which blocks to apply the SA as security source or acceptor. If any of the target block types is not present in the bundle, TBD failure?¶
5. For each of the target block numbers filtered-in by the previous step, the node SHALL apply the service identified by the SOS of the SA, using the Context ID, Key Use Options, and Key Information as defined for each context below.¶

9.3. Binding for BIB-HMAC-SHA2 Context

This section defines how a secondary SA can be negotiated for and used by the integrity context of [RFC9173] with context identifier code point 1.¶

$safe-kus /= [
    ctxid: 1,
    options: kus-options-ctxid1 .within safe-proposals
]
kus-options-ctxid1 = kus-map-ctxid1 / [+ kus-map-ctxid1]
kus-map-ctxid1 = {
    ; SHA Variant values from Section 3.3.1 of RFC 9173
    1: uint,
    ; Integrity Scope flags from Section 3.3.3 of RFC 9173
    2: uint,
}

CTX1_KEY_IR = SAFE_OKM(1, 'key_ir', key_length)
CTX1_KEY_RI = SAFE_OKM(1, 'key_ri', key_length)

9.4. Binding for BCB-AES-GCM Context

This section defines how a secondary SA can be negotiated for and used by the confidentiality context of [RFC9173] with context identifier code point 2.¶

$safe-kus /= [
    ctxid: 2,
    options: kus-options-ctxid2 .within safe-proposals
]
kus-options-ctxid2 = kus-map-ctxid2 / [+ kus-map-ctxid2]
kus-map-ctxid2 = {
    ; AES Variant values from Section 4.3.2 of RFC 9173
    1: uint,
    ; AAD Scope flags from Section 4.3.4 of RFC 9173
    2: uint,
}

CTX2_KEY_IR = SAFE_OKM(2, 'key_ir', key_length)
CTX2_KEY_RI = SAFE_OKM(2, 'key_ri', key_length)

9.5. Binding for COSE Context

This section defines how a secondary SA can be negotiated for and used by the COSE context of [I-D.ietf-dtn-bpsec-cose] with context identifier code point 3. The derived keys are suitable for use with COSE encryption or MAC operations between the nodes hosting the SAFE entities.¶

$safe-kus /= [
    ctxid: 3,
    options: kus-options-ctxid3 .within safe-proposals
]
kus-options-ctxid3 = kus-map-ctxid3 / [+ kus-map-ctxid3]
kus-map-ctxid3 = {
    ; COSE alg header values
    3: tstr / int,
}

CTX3_KEY_IR = SAFE_OKM(3, 'key_ir', key_length)
CTX3_BIV_IR = SAFE_OKM(3, 'biv_ir', iv_length)

CTX3_KEY_RI = SAFE_OKM(3, 'key_ri', key_length)
CTX3_BIV_RI = SAFE_OKM(3, 'biv_ri', iv_length)

11.1. Threat: Passive Leak of Data

Because the SAFE protocol uses EDHOC for its initial authentication activity and messaging and uses primary SA data for confidentiality afterward, the only information which is exposed in plaintext are the Security Association Identifier (SAI) values (which are also EDHOC connection identifiers) and SAFE security partial IV (Section 4.5) values.¶

Both of these values are used strictly for uniqueness and can either be generated by a SAFE entity deterministically or randomly. Neither value contains data derived from or correlated to any outside information, so visibility to a passive attacker is not useful to degrade SAFE security. Their visibility could be used by a passive attacker for SAFE traffic analysis.¶

The sizes of ciphertext values in all forms of SAFE PDU can be used by a passive attacker to estimate the types of SAFE activities being performed. To mitigate this threat, it is possible for a SAFE entity to use EDHOC padding EAD (see Section 3.8.1 of [RFC9528]) during the IA activity or SAFE confidential PDU plaintext padding item (see Section 4.4).¶

11.2. Threat: On-Path Modification

The SAI values are necessary to correlate EDHOC messages and to decrypt SAFE PDUs, so must be in plaintext and any on-path attacker modification of these values will cause either the EDHOC negotiation to fail or the SAFE decryption to fail.¶

The IV values are already part of what would be sent with the associated ciphertext, and any modification will cause the SAFE decryption to fail.¶

Both of these conditions are detectable by the receiver being attacked so there is no possibility of the attacker causing undetectable changes.¶

12.1. Well-Known IPN Service

Within the registry group of [IANA-URI], the registry titled "'ipn' Scheme URI Well-known Service Numbers for BPv7" has been updated to include the following entry.¶

12.2. EDHOC Registries

Within the registry group of [IANA-EDHOC], the registry titled "EDHOC Exporter Labels" has been updated to include the following entry.¶

Within the registry group of [IANA-EDHOC], the registry titled "EDHOC External Authorization Data" has been updated to include the following entry.¶

12.3. BP SAFE Registries

A new registry group "Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE)" has been created at [IANA-SAFE].¶

Within the registry group of [IANA-SAFE], the registry titled "SAFE Security Modes" has been created with registration procedures from Table 27 and initial contents of Table 28.¶

Within the registry group of [IANA-SAFE], the registry titled "SAFE Activity Types" has been created with registration procedures from Table 29 and initial contents of Table 30.¶

Within the registry group of [IANA-SAFE], the registry titled "SAFE Message Data Items" has been created with the following initial contents. Each entry in the table indicates which messages are valid for containing the associated data item and the map label by which the item is identified. The registration procedure for this registry is identical to the corresponding "SAFE Activity Types" entry from the first column.¶

This registry includes only well-known data item types; private use labels can be used to include any other data items in a message.¶

Within the registry group of [IANA-SAFE], the registry titled "SAFE Error Type Enumerations" has been created with the following initial contents. These entries are distinct and separate from the "EDHOC Error Codes" registry of [IANA-EDHOC].¶