Delay-Tolerant Networking B. Sipos Internet-Draft RKF Engineering Intended status: Standards Track 16 March 2021 Expires: 17 September 2021 DTN Bundle Protocol Security COSE Security Context draft-bsipos-dtn-bpsec-cose-05 Abstract This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile of COSE and for PKIX certificates are also defined for BPSec interoperation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 September 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Sipos Expires 17 September 2021 [Page 1] Internet-Draft DTN BPSec COSE March 2021 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. PKIX Environments and CA Policy . . . . . . . . . . . . . 4 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. BPSec Security Context . . . . . . . . . . . . . . . . . . . 4 2.1. Security Scope . . . . . . . . . . . . . . . . . . . . . 5 2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Key Containers . . . . . . . . . . . . . . . . . . . 6 2.2.2. Additional Header Maps . . . . . . . . . . . . . . . 7 2.2.3. AAD Scope . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Results . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.1. Integrity Messages . . . . . . . . . . . . . . . . . 10 2.3.2. Confidentiality Messages . . . . . . . . . . . . . . 11 2.4. Key Considerations . . . . . . . . . . . . . . . . . . . 11 2.5. Canonicalization Algorithms . . . . . . . . . . . . . . . 12 2.5.1. Generating AAD . . . . . . . . . . . . . . . . . . . 12 2.5.2. Payload Data . . . . . . . . . . . . . . . . . . . . 13 2.6. Processing . . . . . . . . . . . . . . . . . . . . . . . 13 2.6.1. Node Authentication . . . . . . . . . . . . . . . . . 14 2.6.2. Policy Recommendations . . . . . . . . . . . . . . . 15 3. COSE Profile for BPSec . . . . . . . . . . . . . . . . . . . 15 3.1. COSE Messages . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Interoperability Algorithms . . . . . . . . . . . . . . . 16 3.3. Asymmetric Key Types and Identifiers . . . . . . . . . . 18 3.3.1. Policy Recommendations . . . . . . . . . . . . . . . 19 4. PKIX Certificate Profile . . . . . . . . . . . . . . . . . . 20 4.1. Multiple-Certificate Uses . . . . . . . . . . . . . . . . 21 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 22 6.2. Threat: Untrusted End-Entity Certificate . . . . . . . . 23 6.3. Threat: Certificate Validation Vulnerabilities . . . . . 23 6.4. Threat: BP Node Impersonation . . . . . . . . . . . . . . 23 6.5. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 23 6.6. Threat: Non-Trusted Public Key . . . . . . . . . . . . . 24 6.7. Threat: Passive Leak of Key Material . . . . . . . . . . 24 6.8. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7.1. BPSec Security Contexts . . . . . . . . . . . . . . . . . 25 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 28 A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 29 Sipos Expires 17 September 2021 [Page 2] Internet-Draft DTN BPSec COSE March 2021 A.2. EC Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . . 31 A.3. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 32 A.4. Symmetric KEK COSE_Encrypt . . . . . . . . . . . . . . . 34 A.5. EC Keypair COSE_Encrypt . . . . . . . . . . . . . . . . . 36 A.6. RSA Keypair COSE_Encrypt . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction The Bundle Protocol Security (BPSec) Specification [I-D.ietf-dtn-bpsec] 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 [RFC8152] 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 in Section 2. A bare minimum of interoperability algorithms and algorithm parameters is specified by this document in Section 3. The focus of the recommended algorithms is to allow BPSec to be used in a Public Key Infrastructure (PKI) as described in Section 1.2. Examples of specific uses are provided in Appendix A to aid in implementation support of the interoperability algorithms. 1.1. Scope This document describes a profile of COSE which is tailored for use in BPSec and a method of including full COSE messages within BPSec security blocks. This document does not address: * Policies or mechanisms for issuing Public Key Infrastructure Using X.509 (PKIX) certificates; provisioning, deploying, or accessing certificates and private keys; deploying or accessing certificate revocation lists (CRLs); or configuring security parameters on an individual entity or across a network. * Uses of COSE beyond the profile defined in this document. * How those COSE algorithms are intended to be used within a larger security context. Many header parameters used by COSE (e.g., key identifiers) depend on the network environment and security policy related to that environment. Sipos Expires 17 September 2021 [Page 3] Internet-Draft DTN BPSec COSE March 2021 1.2. PKIX Environments and CA Policy This specification gives requirements about how to use PKIX certificates issued by a Certificate Authority (CA), but does not define any mechanisms for how those certificates come to be. To support the PKIX uses defined in this document, the CA(s) issuing certificates for BP nodes are aware of the end use of the certificate, have a mechanism for verifying ownership of a Node ID, and are issuing certificates directly for that Node ID. BPSec security acceptors authenticate the Node ID of security sources when verifying integrity (see Section 2.6.1) using a public key provided by a PKIX certificate (see Section 2.6.1) following the certificate profile of Section 4. 1.3. Use of CDDL This document defines CBOR structure using the Concise Data Definition Language (CDDL) of [RFC8610]. The entire CDDL structure can be extracted from the XML version of this document using the XPath expression: '//sourcecode[@type="cddl"]' The following initial fragment defines the top-level symbols of this document's CDDL, including the ASB data structure with its parameter/ result sockets. start = bpsec-cose-asb / AAD-structure / primary-block / extension-block / MAC_structure / Sig_structure / Enc_structure / COSE_KeySet 1.4. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. BPSec Security Context This document specifies a single security context for use in both BPSec integrity and confidentiality blocks. This is done to save code points allocated to this specification and to simplify the encoding of COSE-in-BPSec; the BPSec block type uniquely defines the acceptable parameters and COSE messages which can be present. Sipos Expires 17 September 2021 [Page 4] Internet-Draft DTN BPSec COSE March 2021 The COSE security context SHALL have the Security Context ID specified in Section 7.1. Both types of security block can use the same parameters, defined in Section 2.2, to carry public key-related information and each type of security block allows specific COSE message results, defined in Section 2.3. ; Specialize the ASB for this context bpsec-cose-asb = bpsec-context-use< 0, ; Context ID TBD-COSE $bpsec-cose-param, $bpsec-cose-result > $ext-data-asb /= bpsec-cose-asb Figure 1: COSE context declaration CDDL 2.1. Security Scope The scope here refers to the set of information used by the security context to cryptographically bind with the plaintext data being integrity-protected or confidentiality-protected. This information is generically referred to as additional authenticated data (AAD), which is also the term used by COSE to describe the same data. The sources for AAD within the COSE context are described below, controlled by the AAD Scope Flags parameter of Section 2.2.3, and implemented as defined in Section 2.5.1. Bundle 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 target is no longer in its original bundle. Including this data as part of AAD ensures that security target appears in the same bundle that the security source intended. Target Block Metadata When the target block is a canonical block (i.e., not the primary block) it contains its block-type-specific data, which is the subject of the security operation, but also metadata identifying the block. This metadata explicitly excludes the CRC type and value fields because the CRC is derived from the block-type-specific data. Including this data as part of AAD ensures that the target data appears in the same block that the security source intended. Security Block Metadata The BPSec block containing the security Sipos Expires 17 September 2021 [Page 5] Internet-Draft DTN BPSec COSE March 2021 result for which the AAD is assembled also has metadata identifying the block. Including this data as part of AAD ensures that the security result appears in the same block that the security source intended. 2.2. Parameters Each COSE context parameter value SHALL consist of the COSE structure indicated by Table 1 in its decoded (CBOR item) form. Each security block MAY contain any number of each parameter type. When a parameter is not present, the security acceptor SHALL use the Default Value of Table 1. +===========+========================+===============+==============+ | Parameter | Parameter Structure | Reference | Default | | ID | | | Value | +===========+========================+===============+==============+ | 1 | COSE_Key | [RFC8152] | none | +-----------+------------------------+---------------+--------------+ | 2 | COSE_KeySet | [RFC8152] | none | +-----------+------------------------+---------------+--------------+ | 3 | additional-protected | Section 2.2.2 | '' | | | | of this | | | | | document | (empty | | | | | bstr) | +-----------+------------------------+---------------+--------------+ | 4 | additional-unprotected | Section 2.2.2 | {} | | | | of this | | | | | document | (empty | | | | | map) | +-----------+------------------------+---------------+--------------+ | 5 | AAD_Scope | Section 2.2.3 | 0x7 | | | | of this | | | | | document | (all AAD | | | | | contexts) | +-----------+------------------------+---------------+--------------+ Table 1: COSE Security Parameters 2.2.1. Key Containers Implementations capable of handling asymmetric-keyed algorithms SHOULD support the public key handling COSE_Key and COSE_KeySet parameters. Sipos Expires 17 September 2021 [Page 6] Internet-Draft DTN BPSec COSE March 2021 No more than one total COSE_Key or COSE_KeySet parameter SHALL be present in a single security block. Security acceptors are sill required to aggregate multiple parameters, if present, in Section 3.3. Key container parameters SHALL NOT contain any private key material. The security parameters are all stored in the bundle as plaintext and are visible to any bundle handlers. $bpsec-cose-param /= [1, COSE_Key] $bpsec-cose-param /= [2, COSE_KeySet] Figure 2: Key Containers CDDL 2.2.2. Additional Header Maps The two parameters Additional Protected and Additional Unprotected allow de-duplicating header items which are common to all COSE results. Both additional header values contain a CBOR map which is to be merged with each of the result's unprotected headers. Although the additional header items are all treated as unprotected from the perspective of the COSE message, the additional protected map is included within the "external_aad" (see Section 2.5.1). The expected use of additional header map is to contain a certificate (chain) or identifier (see Section 3.3) which applies to all results in the same security block. Following the same pattern as COSE, when both additional header maps are present in a single security block they SHALL not contain any duplicated labels. Security acceptors SHALL treat a pair of additional header maps containing duplicated labels as invalid. No more than one of each Additional Protected and Additional Unprotected parameter SHALL be present in a single security block. Security acceptors SHALL treat a security block with multiple instances of either additional header type as invalid. There is no well-defined behavior for a security acceptor to handle multiple Additional Protected parameters. Security sources SHOULD NOT include an additional header parameter which represents an empty map. Security acceptors SHALL handle empty header map parameters, specifically the Additional Protected parameter because it is part of the external_aad. Sipos Expires 17 September 2021 [Page 7] Internet-Draft DTN BPSec COSE March 2021 Security acceptors SHALL treat the aggregate of both additional header maps as being present in the "unprotected" header map of the COSE message of each result. If the same header label is present in a additional header map and a result message the item in the result message SHALL take precedence (i.e., the additional header items are added only if they are not already present in a result message). Additional header maps SHALL NOT contain any private key material. The security parameters are all stored in the bundle as plaintext and are visible to any bundle handlers. $bpsec-cose-param /= [3, additional-protected] additional-protected = empty_or_serialized_map $bpsec-cose-param /= [4, additional-unprotected] additional-unprotected = header_map Figure 3: Additional Headers CDDL 2.2.3. AAD Scope The AAD Scope parameter controls what data is included in the AAD for both integrity and confidentiality operations. The AAD Scope parameter SHALL be encoded as a uint value with bit flags defined in Table 2. All reserved bits SHALL be set to zero (which will be elided by CBOR encoding) by security sources. All reserved bits SHALL be ignored by security acceptors. The default value for this parameter has all flags set, meaning the AAD includes all available context. A CDDL representation of this definition is included in Figure 4 for reference. Sipos Expires 17 September 2021 [Page 8] Internet-Draft DTN BPSec COSE March 2021 +==================+========+===============================+ | Name | Code | Description | +==================+========+===============================+ | has-primary-ctx | 0x01 | If bit is set, indicates that | | | | the primary block is included | | | | in AAD scope. | +------------------+--------+-------------------------------+ | has-target-ctx | 0x02 | If bit is set, indicates that | | | | the target block metadata is | | | | included in AAD scope. | +------------------+--------+-------------------------------+ | has-security-ctx | 0x04 | If bit is set, indicates that | | | | the security block metadata | | | | is included in AAD scope. | +------------------+--------+-------------------------------+ | Reserved | others | | +------------------+--------+-------------------------------+ Table 2: AAD Scope Flags $bpsec-cose-param /= [5, AAD-scope] AAD-scope = uint .bits AAD-scope-flags AAD-scope-flags = &( has-primary-ctx: 0, has-target-ctx: 1, has-security-ctx: 2, ) Figure 4: AAD Scope CDDL 2.3. Results Although each COSE context result is a COSE message, the types of message allowed depend upon the security block type in which the result is present: only MAC or signature messages are allowed in a BIB and only encryption messages are allowed in a BCB. The code points for Result ID values are identical to the existing COSE message-marking tags in Section 2 of [RFC8152]. This avoids the need for value-mapping between code points of the two registries. When embedding COSE messages, the message CBOR structure SHALL be encoded as a byte string used as the result value. This allows a security acceptor to skip over unwanted results without needing to decode the result structure. When embedding COSE messages, the CBOR- tagged form SHALL NOT be used. The Result ID values already provide the same information as the COSE tags (using the same code points). Sipos Expires 17 September 2021 [Page 9] Internet-Draft DTN BPSec COSE March 2021 These generic requirements are formalized in the CDDL fragment of Figure 5. $bpsec-cose-result /= [16, bstr .cbor COSE_Encrypt0] $bpsec-cose-result /= [17, bstr .cbor COSE_Mac0] $bpsec-cose-result /= [18, bstr .cbor COSE_Sign1] $bpsec-cose-result /= [96, bstr .cbor COSE_Encrypt] $bpsec-cose-result /= [97, bstr .cbor COSE_Mac] $bpsec-cose-result /= [98, bstr .cbor COSE_Sign] Figure 5: COSE context results CDDL 2.3.1. Integrity Messages When used within a Block Integrity Block, the COSE context SHALL allow only the Result IDs from Table 3. Each integrity result value SHALL consist of the COSE message indicated by Table 3 in its untagged encoded form. +===========+====================+===========+ | Result ID | Result Structure | Reference | +===========+====================+===========+ | 97 | encoded COSE_Mac | [RFC8152] | +-----------+--------------------+-----------+ | 17 | encoded COSE_Mac0 | [RFC8152] | +-----------+--------------------+-----------+ | 98 | encoded COSE_Sign | [RFC8152] | +-----------+--------------------+-----------+ | 18 | encoded COSE_Sign1 | [RFC8152] | +-----------+--------------------+-----------+ Table 3: COSE Integrity Results Each integrity result SHALL use the "detached" payload form with nil payload value. The integrity result for COSE_Mac and COSE_Mac0 messages are computed by the procedure in Section 6.3 of [RFC8152]. The integrity result for COSE_Sign and COSE_Sign1 messages are computed by the procedure in Section 4.4 of [RFC8152]. The COSE "protected attributes from the application" used for a signature or MAC result SHALL be the encoded data defined in Section 2.5.1. The COSE payload used for a signature or MAC result SHALL be either the block-type-specific data of the target, if the target is not the primary block, or an empty byte string if the target is the primary block. Sipos Expires 17 September 2021 [Page 10] Internet-Draft DTN BPSec COSE March 2021 2.3.2. Confidentiality Messages When used within a Block Confidentiality Block, COSE context SHALL allow only the Result IDs from Table 4. Each confidentiality result value SHALL consist of the COSE message indicated by Table 4 in its untagged encoded form. +===========+=======================+===========+ | Result ID | Result Structure | Reference | +===========+=======================+===========+ | 96 | encoded COSE_Encrypt | [RFC8152] | +-----------+-----------------------+-----------+ | 16 | encoded COSE_Encrypt0 | [RFC8152] | +-----------+-----------------------+-----------+ Table 4: COSE Confidentiality Results 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. Security acceptors MUST NOT assume that the size of the plaintext is the same as the size of the ciphertext. Each confidentiality result SHALL use the "detached" payload form with nil payload value. The confidentiality result for COSE_Encrypt and COSE_Encrypt0 messages are computed by the procedure in Section 5.3 of [RFC8152]. The COSE "protected attributes from the application" used for an encryption result SHALL be the encoded data defined in Section 2.5.1. The COSE payload used for an encryption result SHALL be the block- type-specific data of the target. Because confidentiality of the primary block is disallowed by BPSec, there is no logic here for handling a BCB with a target on the primary block. 2.4. Key Considerations This specification does not impose any additional key requirements beyond those already specified for each COSE algorithm required in Section 3. Sipos Expires 17 September 2021 [Page 11] Internet-Draft DTN BPSec COSE March 2021 2.5. Canonicalization Algorithms Generating or processing COSE messages for the COSE context follows the profile defined in Section 3 with the "protected attributes from the application" (i.e., the "external_aad" item) generated as defined in Section 2.5.1. 2.5.1. Generating AAD The AAD used for both integrity and confidentiality messages SHALL be the deterministically encoded form of a CBOR array containing the following: 1. The first item SHALL be either: the CBOR array (unencoded) form of the primary block of the bundle if the AAD Scope has the has- primary-ctx flag set, otherwise the null value. 2. The second item SHALL be either: a CBOR array containing the first three fields of the target block (i.e., the block type code, block number, and control flags) if the AAD Scope has the has-target-ctx flag set, otherwise the null value. 3. The third item SHALL be either: a CBOR array containing the first three fields of the security block containing the result (i.e., the block type code, block number, and control flags) if the AAD Scope has the has-security-ctx flag set, otherwise the null value. 4. The fourth item SHALL be the Additional Protected header map, which is a bstr value and has a default value of the empty bstr. A CDDL representation of this data is shown below in Figure 6. Sipos Expires 17 September 2021 [Page 12] Internet-Draft DTN BPSec COSE March 2021 AAD-structure = [ ; non-null if has-primary-ctx is set primary-ctx: null / primary-block, ; non-null if has-target-ctx is set target-ctx: null / block-metadata, ; non-null if has-security-ctx is set security-ctx: null / block-metadata, ; copy of additional-protected (or default) additional-protected ] ; The first three fields of BP "canonical-block-structure" block-metadata = [ block-type-code: uint, block-number: uint, block-control-flags, ] Figure 6: COSE context AAD CDDL 2.5.2. Payload Data When correlating between BPSec target block-type-specific-data and COSE plaintext or payload, any byte string SHALL be handled in its decoded (CBOR item) form. This means any CBOR header or tag in a source encoding are ignored for the purposes of security processing. This also means that if the source byte string was encoded in a non- conforming way, for example in indefinite-length form or with a non- minimum-size length, the security processing always treats it in a deterministically encoded CBOR form. 2.6. Processing This section describes block-level requirements for handling COSE security data. Security results generated for BIB or BCB results SHALL conform to the COSE profile of Section 3. Sipos Expires 17 September 2021 [Page 13] Internet-Draft DTN BPSec COSE March 2021 2.6.1. Node Authentication This section explains how the certificate profile of Section 4 is used by a security acceptor to both validate an end-entity certificate and to use that certificate to authenticate the security source for an integrity result. For a confidentiality result, some of the requirements in this section are implicit in an implementation using a private key associated with a certificate used by a result recipient. It is an implementation matter to ensure that a BP agent is configured to generate or receive results associated with valid certificates. A security source MAY prohibit generating a result (either integrity or confidentiality) for an end-entity certificate which is not considered valid according to Section 2.6.1.2. Generating a result which is likely to be discarded is wasteful of bundle size and transport resources. 2.6.1.1. Certificate Identification Because of the standard policy of using separate certificates for transport, signing, and encryption (see Section 4.1) a single Node ID is likely to be associated with multiple certificates, and any or all of those certificates MAY be present within an "x5bag" in an Additional Protected parameter (see Section 2.2.2). When present, a security acceptor SHALL use an "x5chain" or "x5t" to identify an end- entity certificate to use for result processing. Security acceptors SHALL NOT assume that a validated certificate containing a NODE-ID matching a security source is enough to associate a certificate with a COSE message or recipient (see Section 3.3). 2.6.1.2. Certificate Validation For each end-entity certificate contained in or identified by by a COSE result, the security acceptor SHALL perform the certification path validation of Section 6 of [RFC5280] up to one of the acceptor's trusted CA certificates. When evaluating a certificate Validity period, the security acceptor SHALL use the bundle Creation Timestamp time (if not unknown) as the reference instead of the current time. If enabled by local policy, the entity SHALL perform an OCSP check of each certificate providing OCSP authority information in accordance with [RFC6960]. If certificate validation fails or if security policy disallows a certificate for any reason, the acceptor SHALL treat the associated security result as failed. Leaving out part of the certification chain can cause the entity to fail to validate a certificate if the left-out certificates are unknown to the entity (see Section 6.2). Sipos Expires 17 September 2021 [Page 14] Internet-Draft DTN BPSec COSE March 2021 For each end-entity certificate contained in or identified by a COSE context result, the security acceptor SHALL apply security policy to the Key Usage extension (if present) and Extended Key Usage extension (if present) in accordance with Section 4.2.1.12 of [RFC5280] and the profile in Section 4. 2.6.1.3. Node ID Authentication If required by security policy, for each end-entity certificate referenced by a COSE context integrity result the security acceptor SHALL validate the certificate NODE-ID in accordance with Section 6 of [RFC6125] using the NODE-ID reference identifier from the Security Source of the containing security block. If the NODE-ID validation result is Failure or if the result is Absent and security policy requires an authenticated Node ID, the security acceptor SHALL treat the result as failed. 2.6.2. Policy Recommendations A RECOMMENDED security policy is to enable the use of OCSP checking when internet connectivity is present. A RECOMMENDED security policy is that if an Extended Key Usage is present that it needs to contain "id-kp-bundleSecurity" to be usable as an end-entity certificate for COSE security results. A RECOMMENDED security policy is to require a validated Node ID (of Section 2.6.1.3) and to ignore any other identifiers in the end-entity certificate. This policy relies on and informs the certificate requirements in Section 3.3.1 and Section 4. This policy assumes that a DTN-aware CA (see Section 1.2) will only issue a certificate for a Node ID when it has verified that the private key holder actually controls the DTN node; this is needed to avoid the threat identified in Section 6.4. This policy requires that a certificate contain a NODE-ID and allows the certificate to also contain network-level identifiers. A tailored policy on a more controlled network could relax the requirement on Node ID validation and/or Extended Key Usage presence. 3. COSE Profile for BPSec This section contains requirements which apply to the use of COSE within BPSec across any security context use. 3.1. COSE Messages When generating a BPSec result, security sources SHALL use encode COSE labels with a uint value. When processing a BPSec result, security acceptors MAY handle COSE labels with with a tstr value. Sipos Expires 17 September 2021 [Page 15] Internet-Draft DTN BPSec COSE March 2021 When used in a BPSec result, each COSE message SHALL contain an explicit algorithm identifier in the lower (content) layers. When available and not implied by the bundle source, a COSE message SHALL contain a key identifier in the highest (recipient) layer. See Section 3.3 for specifics about asymmetric key identifiers. When a key identifier is not available, BPSec acceptors SHALL use the Security Source (if available) and the Bundle Source to imply which keys can be used for security operations. Using implied keys has an interoperability risk, see Section 6.5 for details. A BPSec security operation always occurs within the context of the immutable primary block with its parameters (specifically the Source Node ID) and the security block with its optional Security Source. The algorithms required by this profile focuses on networks using shared symmetric-keys, with recommended algorithms for Elliptic Curve (EC) keypairs and RSA keypairs. The focus of this profile is to enable interoperation between security sources and acceptors on an open network, where more explicit COSE parameters make it easier for BPSec acceptors to avoid assumptions and avoid out-of-band parameters. The requirements of this profile still allow the use of potentially not-easily-interoperable algorithms and message/recipient configurations for use by private networks, where message size is more important than explicit COSE parameters. 3.2. Interoperability Algorithms The set of integrity algorithms needed for interoperability is listed here. The full set of COSE algorithms available is managed at [IANA-COSE]. Implementations conforming to this specification SHALL support the symmetric keyed and key-encryption algorithms of Table 5. Implementations capable of doing so SHOULD support the asymmetric keyed and key-encryption algorithms of Table 5. | The layer-1 required list is identical to the | [I-D.ietf-dtn-bpsec-default-sc] context list. Sipos Expires 17 September 2021 [Page 16] Internet-Draft DTN BPSec COSE March 2021 +=================+============+============+======+================+ | BPSec Block | COSE | Name | Code | Implementation | | | Layer | | | Requirements | +=================+============+============+======+================+ | Integrity | 1 | HMAC | 5 | Required | | | | 256/256 | | | +-----------------+------------+------------+------+----------------+ | Integrity | 1 | ES256 | -7 | Recommended | +-----------------+------------+------------+------+----------------+ | Integrity | 1 | EdDSA | -8 | Recommended | +-----------------+------------+------------+------+----------------+ | Integrity | 1 | PS256 | -37 | Recommended | +-----------------+------------+------------+------+----------------+ | Confidentiality | 1 | A256GCM | 3 | Required | +-----------------+------------+------------+------+----------------+ | Confidentiality | 2 | A256KW | -5 | Required | +-----------------+------------+------------+------+----------------+ | Confidentiality | 2 | ECDH-ES + | -31 | Recommended | | | | A256KW | | | +-----------------+------------+------------+------+----------------+ | Confidentiality | 2 | ECDH-SS + | -34 | Recommended | | | | A256KW | | | +-----------------+------------+------------+------+----------------+ | Confidentiality | 2 | RSAES-OAEP | -41 | Recommended | | | | w/ SHA-256 | | | +-----------------+------------+------------+------+----------------+ Table 5: Interoperability Algorithms The following are recommended key and recipient uses within COSE/ BPSec: Symmetric Key Integrity: When generating a BIB result from a symmetric key, implementations SHALL use a COSE_Mac0 using the private key directly. When a COSE_Mac0 is used with a direct key, the headers SHALL include a key identifier ("kid" header). EC Keypair Integrity: When generating a BIB result from an EC keypair, implementations SHALL use a COSE_Sign1 using the private key directly. When a COSE_Sign1 is used with an EC keypair, the headers SHALL include a public key identifier (see Section 3.3). RSA Keypair Integrity: When generating a BIB result from an RSA Sipos Expires 17 September 2021 [Page 17] Internet-Draft DTN BPSec COSE March 2021 keypair, implementations SHALL use a COSE_Sign1 using the private key directly. When a COSE_Sign1 is used with an RSA keypair, the headers SHALL include a public key identifier (see Section 3.3). When a COSE signature is generated with an RSA keypair, the signature uses a PSS salt in accordance with Section 2 of [RFC8230]. Symmetric Key Confidentiality: When generating a BCB result from an symmetric key, implementations SHALL use a COSE_Encrypt message with a recipient containing an indirect (wrapped or derived) content encryption key (CEK). When generating a BCB result from a symmetric key, implementations SHOULD NOT use COSE_Encrypt0 or COSE_Encrypt with direct CEK. Doing so risks key overuse and the vulnerabilities associated with large amount of ciphertext from the same key. When a COSE_Encrypt is used with an overall key- encryption key (KEK), the recipient layer SHALL include a key identifier for the KEK. EC Keypair Confidentiality: When generating a BCB result from an EC keypair, implementations SHALL use a COSE_Encrypt message with a recipient containing an indirect (wrapped or derived) CEK. When a COSE_Encrypt is used with an EC keypair, the recipient layer SHALL include a public key identifier (see Section 3.3). When a COSE_Encrypt is used with an EC keypair, the security source SHALL either generate an ephemeral EC keypair or choose a unique PartyU Nonce for each security operation. When processing a COSE_Encrypt with an EC keypair, the security acceptor SHALL process all KDF and HMAC context data from the recipient headers in accordance with Section 11.2 of [RFC8152] even though the source is not required to provide any of those parameters. RSA Keypair Confidentiality: When generating a BCB result from an RSA keypair, implementations SHALL use a COSE_Encrypt message with a recipient containing a key-wrapped CEK. When a COSE_Encrypt is used with an RSA keypair, the recipient layer SHALL include a public key identifier (see Section 3.3). 3.3. Asymmetric Key Types and Identifiers This section applies when a BIB uses a public key for verification, or when a BCB uses a public key for encryption. When using asymmetric keyed algorithms, the security source SHALL include a public key identifier as a recipient header. The public key identifier SHALL be either a "kid" of [RFC8152], an "x5t" or "x5chain" of [I-D.ietf-cose-x509], or an equivalent identifier. Sipos Expires 17 September 2021 [Page 18] Internet-Draft DTN BPSec COSE March 2021 When a BIB result contains a "kid" identifier, the security source MAY include an appropriate COSE public key "COSE_Key" in a key container security parameter (see Section 2.2.1). When BIB result contains a "x5t" identifier, the security source MAY include an appropriate PKIX certificate container ("x5chain" or "x5bag" of [I-D.ietf-cose-x509]) in a direct COSE header or an additional header security parameter (see Section 2.2.2). When a BIB result contains an "x5chain", the security source SHOULD NOT also include an "x5t" as the first certificate in the chain is implicitly the applicable end- entity certificate. For a BIB, if all potential security acceptors are known to possess related public key and/or certificate data then the public key or additional header parameters can be omitted. Risks of not including related data are described in Section 6.5 and Section 6.6. When present, public keys and certificates SHOULD be included as additional header parameters rather than within result COSE messages. This provides size efficiency when multiple security results are present because they will all be from the same security source and likely share the same public key material. Security acceptors SHALL still process public keys or certificates present in a result message or recipient as applying to that individual COSE level. Security acceptors SHALL aggregate all COSE_Key objects from all parameters within a single BIB or BCB, independent of encoded type or order of parameters. Because each context contains a single set of security parameters which apply to all results in the same context, security acceptors SHALL treat all public keys as being related to the security source itself and potentially applying to every result. 3.3.1. Policy Recommendations The RECOMMENDED priority policy for including PKIX material for BIB results is as follows: 1. When receivers are not known to possess certificate chains, a full chain is included (as an "x5chain"). 2. When receivers are known to possess root and intermediate CAs, just the end-entity certificate is included (again as an "x5chain"). 3. When receivers are known to possess associated chains including end-entity certificates, a certificate thumbnail (as an "x5t"). 4. Some arbitrary identifier is used to correlate to an end-entity certificate (as a "kid"). Sipos Expires 17 September 2021 [Page 19] Internet-Draft DTN BPSec COSE March 2021 5. The BIB Security Source is used to imply an associated end-entity certificate which identifies that Node ID. When PKIX certificates are used by security acceptors and the end- entity certificate is not explicitly trusted (i.e. pinned), the security acceptor SHALL perform the certification path validation of Section 2.6.1.2 up to one or more trusted CA certificates. Leaving out part of the certification chain can cause the security acceptor to fail to validate a BIB if the left-out certificates are unknown to the acceptor (see Section 6.6). Any end-entity certificate associated with a BPSec security source SHALL adhere to the profile of Section 4. 4. PKIX Certificate Profile This section contains requirements on certificates used for the COSE context, while Section 3.3 contains requirements for how such certificates are transported or identified. All end-entity certificates used for BPSec SHALL conform to [RFC5280], or any updates or successors to that profile. This profile requires Version 3 certificates due to the extensions used by this profile. Security acceptors SHALL reject as invalid Version 1 and Version 2 end-entity certificates. Security acceptors SHALL accept certificates that contain an empty Subject field or contain a Subject without a Common Name. Identity information in end-entity certificates is contained entirely in the subjectAltName extension as a NODE-ID, as defined in [I-D.ietf-dtn-tcpclv4]. All end-entity and CA certificates used for BPSec SHOULD contain both a Subject Key Identifier extension in accordance with Section 4.2.1.2 of [RFC5280] and an Authority Key Identifier extension in accordance with Section 4.2.1.1 of [RFC5280]. Security acceptors SHOULD NOT rely on either a Subject Key Identifier and an Authority Key Identifier being present in any received certificate. Including key identifiers simplifies the work of an entity needing to assemble a certification chain. A BPSec end-entity certificate SHALL contain a NODE-ID which authenticates the Node ID of the security source (for integrity) or the security acceptor (for confidentiality). The identifier type NODE-ID is defined in [I-D.ietf-dtn-tcpclv4]. Sipos Expires 17 September 2021 [Page 20] Internet-Draft DTN BPSec COSE March 2021 When allowed by CA policy, a BPSec end-entity certificate SHOULD contain a PKIX Extended Key Usage extension in accordance with Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage extension is present, it SHALL contain a key purpose "id-kp- bundleSecurity" of [IANA-SMI]. The "id-kp-bundleSecurity" purpose MAY be combined with other purposes in the same certificate. When allowed by CA policy, a BPSec end-entity certificate SHALL contain a PKIX Key Usage extension in accordance with Section 4.2.1.3 of [RFC5280]. The PKIX Key Usage bits which are consistent with COSE security are: digitalSignature, nonRepudiation, keyEncipherment, and keyAgreement. The specific algorithms used by COSE messages in security results determine which of those key uses are exercised. See Section 4.1 for discussion of key use policies across multiple certificates. A BPSec end-entity certificate MAY contain an Online Certificate Status Protocol (OCSP) URI within an Authority Information Access extension in accordance with Section 4.2.2.1 of [RFC5280]. Security acceptors are not expected to have continuous internet connectivity sufficient to perform OCSP verification. 4.1. Multiple-Certificate Uses A RECOMMENDED security policy is to limit asymmetric keys (and thus public key certificates) to single uses among the following: Bundle transport: With key uses as defined in the convergence layer specification(s). Block signing: With key use digitalSignature and/or nonRepudiation. Block encryption: With key use keyEncipherment and/or keyAgreement. This policy is the same one recommended by Section 6 of [RFC8551] for email security and by Section 5.2 of [NIST-SP800-57] more generally. Effectively this means that a BP node uses separate certificates for transport (e.g., as a TCPCL entity), BIB signing (as a security source), and BCB encryption (as a security acceptor). 5. Implementation Status This section is to be removed before publishing as an RFC. [NOTE to the RFC Editor: please remove this section before publication, as well as the reference to [RFC7942] and [github-dtn-bpsec-cose].] Sipos Expires 17 September 2021 [Page 21] Internet-Draft DTN BPSec COSE March 2021 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 [RFC7942]. 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. An example implementation of COSE over Blocks has been created as a GitHub project [github-dtn-bpsec-cose] and is intended to use as a proof-of-concept and as a possible source of interoperability testing. This example implementation only handles CBOR encoding/ decoding and cryptographic functions, it does not construct actual BIB or BCB and does not integrate with a BP Agent. 6. Security Considerations This section separates security considerations into threat categories based on guidance of BCP 72 [RFC3552]. All of the security considerations of the underlying BPSec [I-D.ietf-dtn-bpsec] apply to these new security contexts. 6.1. Threat: BPSec Block Replay The bundle's primary block contains fields which uniquely identify a bundle: the Source Node ID, Creation Timestamp, and fragment parameters (see Section 4.3.1 of [I-D.ietf-dtn-bpbis]). These same fields are used to correlate Administrative Records with the bundles for which the records were generated. Including the primary block in the AAD Scope for integrity and confidentiality (see Section 2.2.3) 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. Sipos Expires 17 September 2021 [Page 22] Internet-Draft DTN BPSec COSE March 2021 6.2. Threat: Untrusted End-Entity Certificate The profile in Section 2.6.1 uses end-entity certificates chained up to a trusted root CA. A security source can include a certificate set which does not contain the full chain, possibly excluding intermediate or root CAs. In an environment where security acceptors are known to already contain needed root and intermediate CAs there is no need to include those CAs, but this has a risk of an acceptor not actually having one of the needed CAs. 6.3. Threat: Certificate Validation Vulnerabilities Even when a security acceptor is operating properly an attacker can attempt to exploit vulnerabilities within certificate check algorithms or configuration to authenticate using an invalid certificate. An invalid certificate exploit could lead to higher- level security issues and/or denial of service to the Node ID being impersonated. There are many reasons, described in [RFC5280] and [RFC6125], why a certificate can fail to validate, including using the certificate outside of its valid time interval, using purposes for which it was not authorized, or using it after it has been revoked by its CA. Validating a certificate is a complex task and can require network connectivity outside of the primary BP convergence layer network path(s) if a mechanism such as OCSP [RFC6960] is used by the CA. The configuration and use of particular certificate validation methods are outside of the scope of this document. 6.4. Threat: BP Node Impersonation When certificates are referenced by BIB results it is possible that the certificate does not contain a NODE-ID or does contain one but has a mismatch with the actual security source (see Section 1.2). Having a CA-validated certificate does not alone guarantee the identity of the security source from which the certificate is provided; additional validation procedures in Section 2.6.1 bind the Node ID based on the contents of the certificate. 6.5. Threat: Unidentifiable Key The profile in Section 3.2 recommends key identifiers when possible and the parameters in section Section 2.2 allow encoding public keys where available. If the application using a COSE Integrity or COSE Confidentiality context leaves out key identification data (in a COSE recipient structure), the security acceptor for those BPSec blocks only has the primary block available to use when verifying or decrypting the target block. This leads to a situation, identified Sipos Expires 17 September 2021 [Page 23] Internet-Draft DTN BPSec COSE March 2021 in BPSec Security Considerations, where a signature is verified to be valid but not from the expected Security Source. Because the key identifier headers are unprotected (see Section 3.3), there is still the possibility that an active attacker removes or alters key identifier(s) in the result. This can cause the security acceptor to not be able to properly verify a valid signature or not use the correct private key to decrypt valid ciphertext. 6.6. Threat: Non-Trusted Public Key The profile in Section 3.2 allows the use of PKIX which typically involves end-entity certificates chained up to a trusted root CA. This allows a BIB to contain end-entity certificates not previously known to a security acceptor but still trust the certificate by verifying it up to a trusted CA. In an environment where security acceptors are known to already contain needed root and intermediate CAs there is no need to include those CAs in a proper chain within the security parameters, but this has a risk of an acceptor not actually having one of the needed CAs. Because the security parameters are not included as AAD, there is still the possibility that an active attacker removes or alters certification chain data in the parameters. This can cause the security acceptor to be able to verify a valid signature but not trust the public key used to perform the verification. 6.7. Threat: Passive Leak of Key Material It is important that the key requirements of Section 2.2 apply only to public keys and PKIX certificates. Including non-public key material in ASB parameters will expose that material in the bundle data and over the bundle convergence layer during transport. 6.8. Threat: Algorithm Vulnerabilities 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 [IANA-COSE]. 7. IANA Considerations Registration procedures referred to in this section are defined in [RFC8126]. Sipos Expires 17 September 2021 [Page 24] Internet-Draft DTN BPSec COSE March 2021 7.1. BPSec Security Contexts Within the "Bundle Protocol" registry [IANA-BUNDLE], the following entry has been added to the "BPSec Security Context Identifiers" sub- registry. +==========+=============+=====================+ | Value | Description | Reference | +==========+=============+=====================+ | TBD-COSE | COSE | This specification. | +----------+-------------+---------------------+ Table 6 8. Acknowledgments The interoperability minimum algorithms and parameters are based on the draft [I-D.ietf-dtn-bpsec-default-sc]. 9. References 9.1. Normative References [IANA-BUNDLE] IANA, "Bundle Protocol", . [IANA-COSE] IANA, "CBOR Object Signing and Encryption (COSE)", . [IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 Sipos Expires 17 September 2021 [Page 25] Internet-Draft DTN BPSec COSE March 2021 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages", RFC 8230, DOI 10.17487/RFC8230, September 2017, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [I-D.ietf-dtn-bpsec] Birrane, E. and K. McKeever, "Bundle Protocol Security Specification", Work in Progress, Internet-Draft, draft- ietf-dtn-bpsec-26, 8 January 2021, . [I-D.ietf-dtn-tcpclv4] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- Tolerant Networking TCP Convergence Layer Protocol Version Sipos Expires 17 September 2021 [Page 26] Internet-Draft DTN BPSec COSE March 2021 4", Work in Progress, Internet-Draft, draft-ietf-dtn- tcpclv4-24, 7 December 2020, . [I-D.ietf-cose-x509] Schaad, J., "CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates", Work in Progress, Internet-Draft, draft- ietf-cose-x509-08, 14 December 2020, . 9.2. Informative References [NIST-SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General", NIST Special Publication 800-57 Revision 4, DOI 10.6028/ NIST.SP.800-57pt1r5, May 2020, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [I-D.ietf-dtn-bpbis] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Version 7", Work in Progress, Internet-Draft, draft-ietf- dtn-bpbis-31, 25 January 2021, . [I-D.ietf-dtn-bpsec-default-sc] Birrane, E., "BPSec Default Security Contexts", Work in Progress, Internet-Draft, draft-ietf-dtn-bpsec-default-sc- 00, 26 January 2021, . [github-dtn-bpsec-cose] Sipos, B., "DTN Bundle Protocol Security COSE Security Context", . Sipos Expires 17 September 2021 [Page 27] Internet-Draft DTN BPSec COSE March 2021 [github-dtn-demo-agent] Sipos, B., "Demo Convergence Layer Agent", . Appendix A. Examples These examples are intended to have the correct structure of COSE security blocks but in some cases use simplified algorithm parameters or smaller key sizes than are required by the actual COSE profile defined in this documents. Each example indicates how it differs from the actual profile if there is a meaningful difference. All of these examples operate within the context of the bundle primary block of Figure 7 with a security target block of Figure 8. All example figures use the extended diagnostic notation [RFC8610]. [ 7, / BP version / 0, / flags / 0, / CRC type / [1, "//dst/svc"], / destination / [1, "//src/"], / source / [1, "//src/"], / report-to / [0, 40], / timestamp / 1000000 / lifetime / ] Figure 7: Primary block CBOR diagnostic [ 7, / type code - bundle age / 2, / block num / 0, / flags / 0, / CRC type / <<300>> / type-specific-data: age / ] Figure 8: Target block CBOR diagnostic All of the examples also operate within a security block containing the AAD Scope parameter with only "has-primary-ctx" and "has-target- ctx" flags set. This results in a consistent AAD-structure as shown in Figure 9, which is encoded as the byte string for COSE external_aad in all of the examples. Sipos Expires 17 September 2021 [Page 28] Internet-Draft DTN BPSec COSE March 2021 [ [ 7, 0, 0, [ 1, "//dst/svc" ], [ 1, "//src/" ], [ 1, "//src/" ], [ 0, 40 ], 1000000 ], / primary-ctx / [ 7, 2, 0 ], / target-ctx / null, / security-ctx / '' / additional-protected / ] Figure 9: Example scope AAD-structure CBOR diagnostic The only differences between these examples which use EC or RSA keypairs and a use of a PKIX public key certificate are: the parameters would have an x5chain parameter instead of a COSE_Key type, and the recipient would contain an "x5t" value instead of a "kid" value. Neither of these is a change to a protected header so, given the same private key, there would be no change to the signature or wrapped-key data. Because each of the encryption examples use the same CEK within the same AAD, the target ciphertext is also identical. The target block after application of the encryption is shown in Figure 10. [ 7, / type code - bundle age / 2, / block num / 0, / flags / 0, / CRC type / h'63bb166949afd31b50841ee05153b9cfaf788d' / ciphertext / ] Figure 10: Encrypted Target block CBOR diagnostic A.1. Symmetric Key COSE_Mac0 This is an example of a MAC with recipient having a 256-bit symmetric key identified by a "kid". [ { / kty / 1: 4, / symmetric / / kid / 2: 'ExampleMAC', / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 99dbae4ce45c' } ] Figure 11: Symmetric Key Sipos Expires 17 September 2021 [Page 29] Internet-Draft DTN BPSec COSE March 2021 The external_aad is the encoded data from Figure 9. The payload is the encoded target block-type-specific data from Figure 8. [ "MAC0", / context / h'a10105', / protected / h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 72632f820018281a000f424083070200f640', / external_aad / h'19012c' / payload / ] Figure 12: MAC_structure CBOR diagnostic [ [2], / targets / 0, / security context TBD-COSE / 1, / flags: params-present / [ / parameters / [ 5, / AAD-scope / 0x03 / has-primary-ctx | has-target-ctx / ] ], [ [ / target block #2 / [ / result / 17, / COSE_Mac0 tag / <<[ <<{ / protected / / alg / 1:5 / HMAC 256//256 / }>>, { / unprotected / / kid / 4:'ExampleMAC' }, null, / payload detached / h'fa8b08724db1f0f4097156b12e65a1e7d57cfcdd413ced62d9e20f2b a4efcea5' / tag / ]>> ] ] ] ] Figure 13: Abstract Security Block CBOR diagnostic Sipos Expires 17 September 2021 [Page 30] Internet-Draft DTN BPSec COSE March 2021 A.2. EC Keypair COSE_Sign1 This is an example of a signature with a recipient having a P-256 curve EC keypair identified by a "kid". The associated public key is included as a security parameter. [ { / signing private key / / kty / 1: 2, / EC2 / / kid / 2: 'ExampleEC2', / crv / -1: 1, / P-256 / / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5 e4fe0a1787a8', / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc 1639960a0c7a', / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51 89786ea63842' } ] Figure 14: Example Keys The external_aad is the encoded data from Figure 9. The payload is the encoded target block-type-specific data from Figure 8. [ "Signature1", / context / h'a10126', / protected / h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 72632f820018281a000f424083070200f640', / external_aad / h'19012c' / payload / ] Figure 15: Sig_structure CBOR diagnostic Sipos Expires 17 September 2021 [Page 31] Internet-Draft DTN BPSec COSE March 2021 [ [2], / targets / 0, / security context TBD-COSE / 1, / flags: params-present / [ / parameters / [ 5, / AAD-scope / 0x03 / has-primary-ctx | has-target-ctx / ] ], [ [ / target block #2 / [ / result / 18, / COSE_Sign1 tag / <<[ <<{ / protected / / alg / 1:-7 / ES256 / }>>, { / unprotected / / kid / 4:'ExampleEC2' }, null, / payload detached / h'66358aa1ee41276688e417d7686db3914f3a6d061a31145912fc18ac 68c1b980e9bbae2d18887677f9f8fb1d0a6133e62d89a2616826fd1109620122cde6 eb5c' / signature / ]>> ] ] ] ] Figure 16: Abstract Security Block CBOR diagnostic A.3. RSA Keypair COSE_Sign1 This is an example of a signature with a recipient having a 1024-bit RSA keypair identified by a "kid". The associated public key is included as a security parameter. This key strength is not supposed to be a secure configuration, only intended to explain the procedure. This signature uses a random salt, so the full signature output is not deterministic. Sipos Expires 17 September 2021 [Page 32] Internet-Draft DTN BPSec COSE March 2021 [ { / signing private key / / kty / 1: 3, / RSA / / kid / 2: 'ExampleRSA', / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29 25', / e / -2: h'010001', / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f 01', / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e c3d00e75', / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955 7effb9f1', / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc 7eea427e1', / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89 05ba3af91', / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65 f4f92865ca3' } ] Figure 17: Example Keys The external_aad is the encoded data from Figure 9. The payload is the encoded target block-type-specific data from Figure 8. [ "Signature1", / context / h'a1013824', / protected / h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 72632f820018281a000f424083070200f640', / external_aad / h'19012c' / payload / ] Figure 18: Sig_structure CBOR diagnostic Sipos Expires 17 September 2021 [Page 33] Internet-Draft DTN BPSec COSE March 2021 [ [2], / targets / 0, / security context TBD-COSE / 1, / flags: params-present / [ / parameters / [ 5, / AAD-scope / 0x03 / has-primary-ctx | has-target-ctx / ] ], [ [ / target block #2 / [ / result / 18, / COSE_Sign1 tag / <<[ <<{ / protected / / alg / 1:-37 / PS256 / }>>, { / unprotected / / kid / 4:'ExampleRSA' }, null, / payload detached / h'8e469941a292d3554c81d1a69330b88563b28b415cf777c694d83272 550d232b57ed4046d03849c2ade086145339872f7712e36ab4c382c1c541185fb15c 036f00fd2842dff3e9d4f4068716d853f7bfe13791521e28faf42db085ab259a009a dceeb2acb7852bec6ec5069fc0d237883da8656aa6773682c3e01bd9732028 c6' / signature / ]>> ] ] ] ] Figure 19: Abstract Security Block CBOR diagnostic A.4. Symmetric KEK COSE_Encrypt This is an example of an encryption with a random CEK and an explicit key-encryption key (KEK) identified by a "kid". The keys used are shown in Figure 20. Sipos Expires 17 September 2021 [Page 34] Internet-Draft DTN BPSec COSE March 2021 [ { / kty / 1: 4, / symmetric / / kid / 2: 'ExampleKEK', / k / -1: h'0e8a982b921d1086241798032fedc1f883eab72e4e43bb2d11cf ae38ad7a972e' }, { / kty / 1: 4, / symmetric / / kid / 2: 'ExampleCEK', / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 99dbae4ce45c' } ] Figure 20: Example Keys The external_aad is the encoded data from Figure 9. [ "Encrypt", / context / h'a10103', / protected / h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 72632f820018281a000f424083070200f640' / external_aad / ] Figure 21: Enc_structure CBOR diagnostic The ASB item for this encryption operation is shown in Figure 22 and corresponds with the updated target block (containing the ciphertext) of Figure 10. Sipos Expires 17 September 2021 [Page 35] Internet-Draft DTN BPSec COSE March 2021 [ [2], / targets / 0, / security context TBD-COSE / 1, / flags: params-present / [ / parameters / [ 5, / AAD-scope / 0x03 / has-primary-ctx | has-target-ctx / ] ], [ [ / target block #2 / [ / result / 96, / COSE_Encrypt tag / <<[ <<{ / protected / / alg / 1:3 / A256GCM / }>>, { / unprotected / / iv / 5: h'6f3093eba5d85143c3dc484a' }, null, / payload detached / [ [ / recipient / h'', / protected / { / unprotected / / alg / 1:-5, / A256KW / / kid / 4:'ExampleKEK' }, h'917f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26 d403a6331159e3d691a708e9984d' / key-wrapped / ] ] ]>> ] ] ] ] Figure 22: Abstract Security Block CBOR diagnostic A.5. EC Keypair COSE_Encrypt This is an example of an encryption with an P-256 curve ephemeral sender keypair and a static recipient keypair identified by a "kid". The keys used are shown in Figure 23. Sipos Expires 17 September 2021 [Page 36] Internet-Draft DTN BPSec COSE March 2021 [ { / sender ephemeral private key / / kty / 1: 2, / EC2 / / crv / -1: 1, / P-256 / / x / -2: h'fedaba748882050d1bef8ba992911898f554450952070aeb4788 ca57d1df6bcc', / y / -3: h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2f493c1c 9c0670f28d62', / d / -4: h'a2e4ed4f2e21842999b0e9ebdaad7465efd5c29bd5761f5c2088 0f9d9c3b122a' }, { / recipient private key / / kty / 1: 2, / EC2 / / kid / 2: 'ExampleEC2', / crv / -1: 1, / P-256 / / x / -2: h'44c1fa63b84f172b50541339c50beb0e630241ecb4eebbddb8b5 e4fe0a1787a8', / y / -3: h'059451c7630d95d0b550acbd02e979b3f4f74e645b74715fafbc 1639960a0c7a', / d / -4: h'dd6e7d8c4c0e0c0bd3ae1b4a2fa86b9a09b7efee4a233772cf51 89786ea63842' }, { / kty / 1: 4, / symmetric / / kid / 2: 'ExampleCEK', / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 99dbae4ce45c' } ] Figure 23: Example Keys The external_aad is the encoded data from Figure 9. [ "Encrypt", / context / h'a10103', / protected / h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 72632f820018281a000f424083070200f640' / external_aad / ] Figure 24: Enc_structure CBOR diagnostic The ASB item for this encryption operation is shown in Figure 25 and corresponds with the updated target block (containing the ciphertext) of Figure 10. Sipos Expires 17 September 2021 [Page 37] Internet-Draft DTN BPSec COSE March 2021 [ [2], / targets / 0, / security context TBD-COSE / 1, / flags: params-present / [ / parameters / [ 5, / AAD-scope / 0x03 / has-primary-ctx | has-target-ctx / ] ], [ [ / target block #2 / [ / result / 96, / COSE_Encrypt tag / <<[ <<{ / protected / / alg / 1:3 / A256GCM / }>>, { / unprotected / / iv / 5: h'6f3093eba5d85143c3dc484a' }, null, / payload detached / [ [ / recipient / h'', / protected / { / unprotected / / alg / 1:-31, / ECDH-ES + A256KW / / kid / 4:'ExampleEC2', / ephemeral key / -1:{ 1:2, -1:1, -2:h'fedaba748882050d1bef8ba992911898f554450952070 aeb4788ca57d1df6bcc', -3:h'ceaa8e7ff4751a4f81c70e98f1713378b0bd82a1414a2 f493c1c9c0670f28d62' } }, h'cb530b03f1e4b09ec1a0ca19afafbf280284106ab407aaf9bfed 6e666c8f2f9ab5465cf11ef02756' / key-wrapped / ] ] ]>> ] ] ] ] Figure 25: Abstract Security Block CBOR diagnostic Sipos Expires 17 September 2021 [Page 38] Internet-Draft DTN BPSec COSE March 2021 A.6. RSA Keypair COSE_Encrypt This is an example of an encryption with a recipient having a 1024-bit RSA keypair identified by a "kid". The associated public key is included as a security parameter. This key strength is not supposed to be a secure configuration, only intended to explain the procedure. This padding scheme uses a random salt, so the full layer-2 ciphertext output is not deterministic. [ { / recipient private key / / kty / 1: 3, / RSA / / kid / 2: 'ExampleRSA', / n / -1: h'b0b5fd85f52c91844007443c9f9371980025f76d51fc9c676812 31da610cb291ba637ce813bffdb2e9c653258607389ec97dad3db295fded67744ed6 20707db36804e74e56a494030a73608fc8d92f2f0578d2d85cc201ef0ff22d7835d2 d147d3b90a6884276235a01c2be99dfc597f79554362fc1eb03639cac5ccaddb29 25', / e / -2: h'010001', / d / -3: h'9b5d26ad6445ef1aab80b809e4f329684e9912d556c4166f041d 1b1fb93c04b4037ffd0dbe6f8a8a86e70bab6e0f6344983a9ada27ed9ff7de816fde eb5e7be48e607ce5fda4581ca6338a9e019fb3689b28934192b6a190cdda910abb5a 86a2f7b6f9cd5011049d8de52ddfef73aa06df401c55623ec196720f54920deb4f 01', / p / -4: h'db22d94e7784a27b568cbf985307ea8d6430ff6b88c18a7086fd 4f57a326572f2250c39e48a6f8e2201661c2dfe12c7386835b649714d050aa36123e c3d00e75', / q / -5: h'ce7016adc5f326b7520397c5978ee2f50e69279983d54c5d76f0 5bcd61de0879d7056c923540dff9cbae95dcc0e5e86b52b3c902dc9669c8021c6955 7effb9f1', / dP / -6: h'6a6fcaccea106a3b2e16bf18e57b7ad9a2488a4758ed68a8af6 86a194f0d585b7477760c738d6665aee0302bcf4237ad0530d83b4b86b887f5a4bdc 7eea427e1', / dQ / -7: h'28a4cae245b1dcb285142e027a1768b9c4af915b59285a93a04 22c60e05edd9e57663afd023d169bd0ad3bd62da8563d231840802ebbf271ad70b89 05ba3af91', / qInv / -8: h'07b5a61733896270a6bd2bb1654194c54e2bc0e061b543a4e d9fa73c4bc79c87148aa92a451c4ab8262b6377a9c7b97f869160ca6f5d853ee4b65 f4f92865ca3' }, { / kty / 1: 4, / symmetric / / kid / 2: 'ExampleCEK', / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e39 99dbae4ce45c' } ] Sipos Expires 17 September 2021 [Page 39] Internet-Draft DTN BPSec COSE March 2021 Figure 26: Example Keys The external_aad is the encoded data from Figure 9. [ "Encrypt", / context / h'a10103', / protected / h'84880700008201692f2f6473742f7376638201662f2f7372632f8201662f2f73 72632f820018281a000f424083070200f640' / external_aad / ] Figure 27: Enc_structure CBOR diagnostic The ASB item for this encryption operation is shown in Figure 28 and corresponds with the updated target block (containing the ciphertext) of Figure 10. Sipos Expires 17 September 2021 [Page 40] Internet-Draft DTN BPSec COSE March 2021 [ [2], / targets / 0, / security context TBD-COSE / 1, / flags: params-present / [ / parameters / [ 5, / AAD-scope / 0x03 / has-primary-ctx | has-target-ctx / ] ], [ [ / target block #2 / [ / result / 96, / COSE_Encrypt tag / <<[ <<{ / protected / / alg / 1:3 / A256GCM / }>>, { / unprotected / / iv / 5: h'6f3093eba5d85143c3dc484a' }, null, / payload detached / [ [ / recipient / h'', / protected / { / unprotected / / alg / 1:-41, / RSAES-OAEP w SHA-256 / / kid / 4:'ExampleRSA' }, h'66e76f3e924674c02c98ddef1cfee0d79718549849d1bb008993 28d4b66c8ac481de1ddd258f20514cfe040ead00afeb0709ef22e67607ef5ab62562 4753cb247152b54240e51e96b5d7fdd37cf97af23e2292d6c6a0d2a8ab25a82b8a6c af1d4fa2f1bd7f1fd17d89506e75a1e2687374aa2a1cf21ce387916039d84ecc14 03' / key-wrapped / ] ] ]>> ] ] ] ] Figure 28: Abstract Security Block CBOR diagnostic Author's Address Sipos Expires 17 September 2021 [Page 41] Internet-Draft DTN BPSec COSE March 2021 Brian Sipos RKF Engineering Solutions, LLC 7500 Old Georgetown Road Suite 1275 Bethesda, MD 20814-6198 United States of America Email: BSipos@rkf-eng.com Sipos Expires 17 September 2021 [Page 42]