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(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
~---------+       +-----------~  ~---------+-+       +--------~
          |       |     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.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 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").¶

Node A     A     A     A     A
     |     ^     |     ^     |
     v     |     v     |     v
Node 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 and Security

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 null value¶

Receiver SAI:

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

When the Partial IV is null, the payload SHALL be one of the EDHOC messages defined in [RFC9528] and handled in accordance with Section 5.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 is a byte string, 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.¶

This is indicated by the following CDDL for the SAFE bundle PDU sequence.¶

; Encoded to PDU as CBOR sequence
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,
    rx-sai: true,
    ; Group message_1 from RFC 9528
    message_1
)
safe-pdu-edhoc //= (
    partial-iv: 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 EAD items
edhoc_234 = bstr

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

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

safe-pdu-aad = (
  rx-sai: safe-sai
)

Within restrictions defined for each message type, multiple messages MAY be combined into a single PDU (as either EDHOC EAD or SAFE plaintext). Due to the logic of the Initial Authentication (IA) 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.5. 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 28 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-data from Section 4.4. 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.¶

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 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. 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: No payload, message is acknowledgement.¶

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)

5.3. 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)

; Optional PRF parameters
$$sc-data //= (2: safe-ake)
$$sc-data //= (3: safe-arn)

; 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 keys
$$sc-data //= (4: safe-kus)

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.3.¶

5.4. SA Teardown (ST)

This activity is used to negotiate removal of an established SA from both entities. 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)

5.5. 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

; SAI for the responder
$$sr-data //= (1: safe-sai)
; KID for the prekey being shared by the initiator
$$cp-data //= (2: safe-kid)
$$cp-data //= (3: safe-nti)
$$cp-data //= (4: safe-ake)

Upon the first reception of CP step 0, the entity SHALL correlate the Local SAI of a Primary SA or Secondary SA and store the prekey information within the SA.¶

5.6. 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 SA Rekey (SR) 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.¶

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

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

; Optional PRF parameters
$$sr-data //= (2: safe-kid)
$$sr-data //= (3: safe-arn)

Upon the first reception or transmission of SR 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.2 or Section 8.4 respectively.¶

5.7. Event Notification (EN)

TBD This activity is used by the initiator to inform the peer entity of an event. The Event Notification (EN) activity SHALL be identified by activity type 7.¶

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

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

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. 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.6. 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.7. Additional Key Exchange (AKE)

This data item indicates the public key of the sender for an additional ECDH exchange to add forward secrecy to a secondary SA. When sent by the activity initiator this is a request for additional key exchange, and when sent by the responder this is the confirmation that a key exchange is supported and desired. The algorithm and parameters related to key exchange are taken from the cipher suite negotiated by the primary SA.¶

; The compressed public key for the same algorithm as the primary SA
safe-ake = bstr

6.8. 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.3) and CK Creation (Section 5.6) 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.9. 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 one-hop (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,
    one-hop: 2,
)

6.10. 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.11. 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.12. 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.13. 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.¶

8.1. Primary SA PRK

The primary SA is used to manage derived data for two independent purposes: content keys for message security between the SAFE endpoints themselves, and as the PRK used to derive secondary SAs between the two SAFE entities.¶

The EDHOC processes which generate the PRK_Exporter secret bind that PRK to all of the transcript hash (TH) data from the EDHOC session, which includes the C_I and C_R identifiers as they are part of EDHOC message 1 and message 2 respectively. Because the primary SA uses those connection identifiers as the SAI for each side of the primary SA creation, there is no additional context needed to derive the PRK for the primary SA. The associated EDHOC_Exporter is used once during primary SA creation to derive a seed PRK for the entire primary SA.¶

PRK_SA1 = EDHOC_Exporter(TBA4, '', hash_length)

An application-level derivation function SAFE_KDF is defined with the same logic as the EDHOC_KDF in Section 4.1.2 of [RFC9528] except using the Hash Algorithm of the Primary SA. The pseudocode defining this KDF is in Figure 17. This KDF is used within each primary SA to derive content keys (Section 8.2) and secondary SA PRKs (Section 8.3).¶

SAFE_KDF(PRK, info_label, context, length)
  = EDHOC_KDF(PRK, info_label, context, length)

A summary of labels used with SAFE_KDF and the PRK_SA1 is listed in Table 14¶

8.2. Primary SA Content Keys

The primary SA key uses 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 the COSE algorithm is one of the AEAD algorithms, the COSE key SHALL contain the following parameters. Notably, these keys do not contain a kid parameter because they are not intended to be referenced from outside of the SAFE entity managing the primary SA.¶

kty (1):

The value Symmetric (4).¶

alg (3):

The negotiated "application AEAD algorithm" from the IA activity.¶

key_ops (4):

Either encrypt (3) if this entity is the IA initiator and the key is for traffic from the initiator side, or decrypt (4) otherwise¶

Base IV (5):

Either BIV_IR (from Figure 18) if the key is for traffic from the initiator side, or BIV_RI otherwise¶

k (-1):

Either K_IR (from Figure 18) if the key is for traffic from the initiator side, or K_RI otherwise¶

Pseudocode used to explain this is shown in Figure 18, 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_FS:

The shared secret derived from Additional Key Exchange (AKE) from both the initiator and responder, or the empty byte string if AKE was not received from both entities¶

PRK_SA1:

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 = KID | ARN | PRK_FS

SK_SA1   = SAFE_KDF(PRK_SA1, 1, context_ck1, key_length)
BIV_SA1 = SAFE_KDF(PRK_SA1, 2, context_ck1, iv_length)

8.3. Secondary SA PRK

The SAFE_KDF is used once during secondary SA creation to derive a seed PRK for the entire secondary SA.¶

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

SAI(i) and SAI(r):

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

ARN(i) and ARN(r):

The Additional Random Nonce (ARN) from the initiator and responder respectively, or the empty byte string if no such data item was received¶

PRK_FS:

The shared secret derived from Additional Key Exchange (AKE) from both the initiator and responder, or the empty byte string if AKE was not received from both entities¶

PRK_SA1:

The PRK from the parent Primary SA.¶

hash_length:

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

context_sa2 = SAI(i) | SAI(r) | ARN(i) | ARN(r) | PRK_FS
PRK_SA2 = SAFE_KDF(PRK_SA1, 0, context_sa2, hash_length)

8.4. 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 20, 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_KDF(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 one-hop (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 confidentiality partial IV (Section 4.4) 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 25 and initial contents of Table 26.¶

Within the registry group of [IANA-SAFE], the registry titled "SAFE Activity Types" 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 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].¶