DTN Bundle Protocol Security COSE Security Contexts
RKF Engineering Solutions, LLC
7500 Old Georgetown RoadSuite 1275BethesdaMD20814-6198United States of AmericaBSipos@rkf-eng.com
Transport
Delay-Tolerant Networking
This document defines an integrity security context and a confidentiality security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) blocks.
The Bundle Protocol Security (BPSec) Specification defines structure and encoding for Block Integrity Block (BIB) and Block Confidentiality Block (BCB) types but does not specify any security contexts to be used by either of the security block types.
The CBOR Object Signing and Encryption (COSE) specification defines a structure, encoding, and algorithms to use for cryptographic signing and encryption.
This document describes how to use the algorithms and encodings of COSE within BPSec blocks to apply those algorithms to Bundle security.
A bare minimum of interoperability algorithms and algorithm parameters is specified by this document.
This document does not address how those COSE algorithms are intended to be used within a larger security context.
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.
Rather than defining a single security context for both integrity and confidentiality blocks, this document specifies two separate security contexts which are analogous to the two BPSec block types.
Each security context allows a specific set of BPSec Result IDs.
The existing COSE structure-marking tags in Section 2 of SHALL be used as BPSec Result ID values for all COSE security contexts (see and ).
This avoids the need for value-mapping between code points of the two registries.
When embedding COSE structures, the CBOR-tagged form SHALL NOT be used.
The Result ID values already provide the same information as the COSE tags.
The COSE Integrity Context has a Security Context ID of TBD-CI.
The integrity context SHALL allow only the Result IDs from .
Each integrity context result value SHALL consist of the COSE structure indicated by in its decoded form.
Result IDResult Structure97COSE_Mac17COSE_Mac098COSE_Sign18COSE_Sign1
Each integrity result SHALL use the "detached" payload form with nil payload value.
The integrity result for COSE_Mac and COSE_Mac0 structures are computed by the procedure in Section 6.3 of .
The integrity result for COSE_Sign and COSE_Sign1 structures are computed by the procedure in Section 4.4 of .
[NOTE: This differs from base BPSec in that the entire block and the bundle primary is signed]
The COSE "payload" used to generate a signature or MAC result SHALL be the canonically serialized target block, including the canonical block array structure.
The COSE "protected attributes from the application" used to generate a signature or MAC result SHALL be either:
An empty byte string.
The canonically serialized primary block of the bundle.
[NOTE: This is identical to the minimum list.]
The minimum set of integrity algorithms needed for interoperability is listed here.
The full set of algorithms available is managed at .
NameCodeHMAC 256/2565
The COSE Confidentiality Context has a Security Context ID of TBD-CC.
The confidentiality context SHALL allow only the Result IDs from .
Each confidentiality context result value SHALL consist of the COSE structure indicated by in its decoded form.
Result IDResult Structure96COSE_Encrypt16COSE_Encrypt0
Only algorithms which support Authenticated Encryption with Authenticated Data (AEAD) SHALL be usable in the first (content) layer of a confidentiality result.
Because COSE encryption with AEAD appends the authentication tag with the ciphertext, the size of the block-type-specific-data will grow after an encryption operation.
Each confidentiality result SHALL use the "detached" payload form with nil payload value.
The COSE plaintext and ciphertext correspond exactly with the target block-type-specific-data.
The confidentiality result for COSE_Encrypt and COSE_Encrypt0 structures are computed by the procedure in Section 5.3 of .
[NOTE: This differs from base BPSec in that AAD from the block and the bundle primary is used]
The COSE "plaintext" used to generate an encrypt result SHALL be the block-type-specific-data of the target block, the decoded byte string itself (not including the encoded CBOR item header).
The COSE "protected attributes from the application" used to generate an encrypt result SHALL be the concatenation of the following:
The canonically serialized primary block of the bundle.
The canonically serialized augmented target block, which has its block-type-specific-data substituted with an empty byte string.
[NOTE: This is identical to the minimum list.]
The minimum set of integrity algorithms needed for interoperability is listed here.
The full set of algorithms available is managed at .
NameCodeA256GCM3
[NOTE to the RFC Editor: please remove this section before publication, as well as the reference to .]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in
.
The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations can exist.
This section separates security considerations into threat categories based on guidance of BCP 72 .
All of the security considerations of the underlying BPSec apply to these new security contexts.
The bundle's primary block contains fields which should uniquely identify a bundle: the Source Node ID, Creation Timestamp, and fragment parameters (see Section 4.2.2 of ).
Including the primary block in the AAD for integrity and confidentiality binds the verification of the secured block to its parent bundle and disallows replay of any block with its BIB or BCB.
This profile of COSE limits the encryption algorithms to only AEAD in order to include the context of the encrypted data as AAD.
If an agent mistakenly allows the use of non-AEAD encryption when decrypting and verifying a BCB, the possibility of block replay attack is present.
Because this use of COSE leaves the specific algorithms chosen for BIB and BCB use up to the applications securing bundle data, it is important to use only COSE algorithms which are marked as recommended in the IANA registry .
Registration procedures referred to in this section are defined in .
Within the "Bundle Protocol" registry , the following entry has been added to the "BPSec Security Context Identifiers" sub-registry.
ValueDescriptionReferenceTBD-CICOSE IntegrityThis specification.TBD-CCCOSE ConfidentialityThis specification.
The interoperability minimum algorithms and parameters are based on the draft .
Bundle ProtocolIANACBOR Object Signing and Encryption (COSE)IANA
This is an example of a MAC with implied recipient (and its key material).
The two provided figures are CBOR diagnostic notation of the target block being signed and the Abstract Security Block (which will itself be enveloped within a BIB).
The 256-bit key used is h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999dbae4ce45c'.
The primary block encodes to h'880700008201462f2f6473742f8201462f2f7372632f8201462f2f7372632f820018281a000f4240'.
The target data to be signed is concatenated from the primary encoded and h'85070200004319012c'.
This is an example of an encryption with implied recipient (and its key material).
The provided figures are CBOR diagnostic notation of the target block being encrypted, the Abstract Security Block (which will itself be enveloped within a BCB), and the resulting target block.
The 256-bit key used is h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999dbae4ce45c'.
The primary block encodes to h'880700008201462f2f6473742f8201462f2f7372632f8201462f2f7372632f820018281a000f4240'.
The target plaintext is h'19012c' with AAD concatenated from the primary encoded and h'850702000040'.
A random IV is generated for this operation and is indicated in a standard way.