Skip to content

RFC 9173: Default Security Contexts for Bundle Protocol Security (BPSec)

  • E. Birrane, III,  
  • A. White,  
  • S. Heiner
Proposed Standard

Abstract

This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (BPSec) implementations. These security contexts are intended to be used both for testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

1. Introduction

The Bundle Protocol Security (BPSec) specification [] provides inter-bundle integrity and confidentiality operations for networks deploying the Bundle Protocol (BP) []. BPSec defines BP extension blocks to carry security information produced under the auspices of some security context.

This document defines two security contexts (one for an integrity service and one for a confidentiality service) for populating BPSec Block Integrity Blocks (BIBs) and Block Confidentiality Blocks (BCBs). This document assumes familiarity with the concepts and terminology associated with BP and BPSec, as these security contexts are used with BPSec security blocks and other BP blocks carried within BP bundles.

These contexts generate information that MUST be encoded using the Concise Binary Object Representation (CBOR) specification documented in [].

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [] [] when, and only when, they appear in all capitals, as shown here.

3. Integrity Security Context BIB-HMAC-SHA2

3.1. Overview

The BIB-HMAC-SHA2 security context provides a keyed-hash Message Authentication Code (MAC) over a set of plaintext information. This context uses the Secure Hash Algorithm 2 (SHA-2) discussed in [SHS] combined with the Hashed Message Authentication Code (HMAC) keyed hash discussed in []. The combination of HMAC and SHA-2 as the integrity mechanism for this security context was selected for two reasons:

  1. The use of symmetric keys allows this security context to be used in places where an asymmetric-key infrastructure (such as a public key infrastructure) might be impractical.
  2. The combination HMAC-SHA2 represents a well-supported and well-understood integrity mechanism with multiple implementations available.

BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the supported length of the SHA-2 hash value. These variants correspond to HMAC 256/256, HMAC 384/384, and HMAC 512/512 as defined in Table 7 ("HMAC Algorithm Values") of []. The selection of which variant is used by this context is provided as a security context parameter.

The output of the HMAC MUST be equal to the size of the SHA2 hashing function: 256 bits for SHA-256, 384 bits for SHA-384, and 512 bits for SHA-512.

The BIB-HMAC-SHA2 security context MUST have the security context identifier specified in Section 5.1.

3.2. Scope

The scope of BIB-HMAC-SHA2 is the set of information used to produce the plaintext over which a keyed hash is calculated. This plaintext is termed the "Integrity-Protected Plaintext (IPPT)". The content of the IPPT is constructed as the concatenation of information whose integrity is being preserved from the BIB-HMAC-SHA2 security source to its security acceptor. There are five types of information that can be used in the generation of the IPPT, based on how broadly the concept of integrity is being applied. These five types of information, whether they are required, and why they are important for integrity are discussed as follows.

Security target contents
The contents of the block-type-specific data field of the security target MUST be included in the IPPT. Including this information protects the security target data and is considered the minimal, required set of information for an integrity service on the security target.
IPPT scope
The determination of which optional types of information were used when constructing the IPPT MUST always be included in the IPPT. Including this information ensures that the scope of the IPPT construction at a security source matches the scope of the IPPT construction at security verifiers and security acceptors.
Primary block

The primary block identifies a bundle, and once created, the contents of this block are immutable. Changes to the primary block associated with the security target indicate that the security target (and BIB) might no longer be in the correct bundle.

For example, if a security target and associated BIB are copied from one bundle to another bundle, the BIB might still contain a verifiable signature for the security target unless information associated with the bundle primary block is included in the keyed hash carried by the BIB.

Including this information in the IPPT protects the integrity of the association of the security target with a specific bundle.

Other fields of the security target

The other fields of the security target include block identification and processing information. Changing this information changes how the security target is treated by nodes in the network even when the "user data" of the security target are otherwise unchanged.

For example, if the block processing control flags of a security target are different at a security verifier than they were originally set at the security source, then the policy for handling the security target has been modified.

Including this information in the IPPT protects the integrity of the policy and identification of the security target data.

Other fields of the BIB

The other fields of the BIB include block identification and processing information. Changing this information changes how the BIB is treated by nodes in the network, even when other aspects of the BIB are unchanged.

For example, if the block processing control flags of the BIB are different at a security verifier than they were originally set at the security source, then the policy for handling the BIB has been modified.

Including this information in the IPPT protects the integrity of the policy and identification of the security service in the bundle.

The scope of the BIB-HMAC-SHA2 security context is configured using an optional security context parameter.