Internet-Draft | DTN BPSec COSE | October 2020 |
Sipos | Expires 1 May 2021 | [Page] |
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 is also defined for BPSec interoperation.¶
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 1 May 2021.¶
Copyright (c) 2020 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.¶
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 3. A bare minimum of interoperability algorithms and algorithm parameters is specified by this document in Section 4.¶
This document does not address how those COSE algorithms are intended to be used within a larger security context. Examples of specific uses are provided in Appendix A to aid in implementation support of the interoperability algorithms.¶
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.¶
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 COSE messages which can be present and each COSE message is type-tagged to indicate its purpose and contents.¶
The COSE security context shall have the Security Context ID specified in Section 7.1.¶
The existing CoAP Content-Format ID values in the CoRE registry [IANA-CORE] SHALL be used as BPSec Parameter ID and Result ID values within COSE security context (see tables within Section 3.1 and Section 3.2). For Result ID values used to identify COSE messages, these code points are also 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 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).¶
When used within a Block Integrity Block, COSE context SHALL allow only the Parameter IDs from Table 1. Each integrity parameter value SHALL consist of the COSE structure indicated by Table 1 in its decoded form.¶
Parameter ID | Parameter Structure | Reference |
---|---|---|
101 | COSE_Key | [RFC8152] |
102 | COSE_KeySet | [RFC8152] |
When used within a Block Integrity Block, COSE context SHALL allow only the Result IDs from Table 2. Each integrity result value SHALL consist of the COSE message indicated by Table 2 in its decoded form.¶
Result ID | Result Structure | Reference |
---|---|---|
97 | COSE_Mac | [RFC8152] |
17 | COSE_Mac0 | [RFC8152] |
98 | COSE_Sign | [RFC8152] |
18 | COSE_Sign1 | [RFC8152] |
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].¶
[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:¶
When used within a Block Confidentiality Block, COSE context SHALL allow only the Parameter IDs from Table 3. Each integrity parameter value SHALL consist of the COSE structure indicated by Table 3 in its decoded form.¶
Parameter ID | Parameter Structure | Reference |
---|---|---|
101 | COSE_Key | [RFC8152] |
102 | COSE_KeySet | [RFC8152] |
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 decoded form.¶
Result ID | Result Structure | Reference |
---|---|---|
96 | COSE_Encrypt | [RFC8152] |
16 | COSE_Encrypt0 | [RFC8152] |
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 messages are computed by the procedure in Section 5.3 of [RFC8152].¶
[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:¶
This section contains requirements which apply to the use of COSE within BPSec across any security context use.¶
When necessary to support public key infrastructure (PKI) within BPSec, a BIB or BCB with a COSE context MAY contain one or more public keys or key identifiers. Because each context contains a single set of parameters which apply to all results in the same context, security acceptors SHALL treat all COSE keys as being related to the security source itself and potentially applying to every result.¶
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.¶
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 SHOULD contain a key identifier in the highest (recipient) layer. When a key identifier is not available, BPSec acceptors SHOULD use the Security Source (if available) and the Bundle Source to imply which keys can be used for security operations. 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.¶
[NOTE: The required list is identical to the [I-D.ietf-dtn-bpsec-interop-sc] list.] 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 algorithms of Table 5. Implementations capable of doing so SHOULD support the asymmetric keyed and key-encryption algorithms of Table 5.¶
BPSec Block | COSE Layer | Name | Code | Implementation Requirements |
---|---|---|---|---|
Integrity | 1 | HMAC 256/256 | 5 | Required |
Integrity | 1 | ES256 | -7 | Recommended |
Integrity | 1 | EdDSA | -8 | Recommended |
Integrity | 1 | PS256 | -37 | Recommended |
Confidentiality | 1 | A256GCM | 3 | Required |
Integrity or Confidentiality | 2 | A256KW | -5 | Recommended |
Integrity or Confidentiality | 2 | ECDH-ES + A256KW | -31 | Recommended |
Integrity or Confidentiality | 2 | RSAES-OAEP w/ SHA-256 | -41 | Recommended |
The following are recommended key and recipient uses within COSE/BPSec:¶
[NOTE to the RFC Editor: please remove this section before publication, as well as the reference to [RFC7942] and [github-dtn-bpsec-cose].]¶
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.¶
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.¶
The bundle's primary block contains fields which uniquely identify a bundle: the Source Node ID, Creation Timestamp, and fragment parameters (see Section 4.2.2 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 for BPSec 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.¶
The profile in Section 4.3 recommends key identifiers when possible and the parameters in section Section 4.1 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 in BPSec Security Considerations, where a signature is verified to be valid but not from the expected Security Source.¶
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].¶
Registration procedures referred to in this section are defined in [RFC8126].¶
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. |
The interoperability minimum algorithms and parameters are based on the draft [I-D.ietf-dtn-bpsec-interop-sc].¶
This is an example of a MAC with implied recipient (and its key material). The provided figures are extended diagnostic notation [RFC8610].¶
The 256-bit key used is shown below.¶
[ { / kty / 1: 4, / symmetric / / kid / 2: 'ExampleMAC', / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999db ae4ce45c' } ]
[ 7, / BP version / 0, / flags / 0, / CRC type / [1, "//dst/svc"], / destination / [1, "//src/bp"], / source / [1, "//src/bp"], / report-to / [0, 40], / timestamp / 1000000 / lifetime / ]
[ 7, / type code - bundle age / 2, / block num / 0, / flags / 0, / CRC type / <<300>> / type-specific-data: age / ]
The external_aad is the encoded primary block. The payload is the encoded target block.¶
[ "MAC0", / context / h'a10105', / protected / h'880700008201692f2f6473742f7376638201682f2f7372632f62708201682f2f7372 632f6270820018281a000f4240', / external_aad / h'85070200004319012c' / payload / ]
[ [2], / targets / 0, / security context TBD / 0, / flags / [ [ / target block #2 / [ / result / 17, / COSE_Mac0 tag / [ <<{ / protected / / alg / 1:5 / HMAC 256//256 / }>>, { / unprotected / / kid / 4:'ExampleMAC' }, null, / payload / h'1349a33b41b020e46669b714b53a1b79db458fdef0f0b7a0daebde6baf27 7472' / tag / ] ] ] ] ]
This is an example of a signature with implied recipient (and its key material). The provided figures are extended diagnostic notation [RFC8610].¶
The 512-bit private key used is below. It is not supposed to be a secure configuration, only intended to explain the procedure. This signature uses zero-length salt for deterministic output, which differs from the parameter specified by [RFC8230] and is not recommended for normal use.¶
[ { / signing private key / / kty / 1: 3, / RSA / / kid / 2: 'ExampleRSA', / n / -1: b64'3bUZ1LR9oBiBpx6lGZuvtMBPTAS5qGOsF8A7QODUzl3fs71PH0e9nDY4RwurZZO9_QqNrUlamp2gmbXsuCGE-Q', / e / -2: b64'AQAB', / d / -3: b64'yCQmj2foSFAXKuB1Nmre8RLyArP5TdO8lSxJ0UWllixmFRoso_2jHIjGXci8rmJLSgCxbSeojtoxwGg-bFmlAQ', / p / -4: b64'7snebs70tMJ67A1qA4Yk5ujvjyaDEIsfch_fRwVIVik', / q / -5: b64'7bAM_t782esDusNKAzr5EQaa3wjTQ2CUXBKEFSLgclE', / dP / -6: b64'Iiay7kwhCV0rMWl1uQ1NZ8z2vhV29z2-gJb4WvLxdok', / dQ / -7: b64'bC7WK2dJBNKv9uCOHlxIItSzxtIYfjFGNYYD8i7Wo5E', / qInv / -8: b64'6efvn6dOADFQJxNLqjRJyE5E1m_dYQEvCI2mAqixshA' } ]
[ 7, / BP version / 0, / flags / 0, / CRC type / [1, "//dst/svc"], / destination / [1, "//src/bp"], / source / [1, "//src/bp"], / report-to / [0, 40], / timestamp / 1000000 / lifetime / ]
[ 7, / type code - bundle age / 2, / block num / 0, / flags / 0, / CRC type / <<300>> / type-specific-data: age / ]
The external_aad is the encoded primary block. The payload is the encoded target block.¶
[ "Signature1", / context / h'a1013824', / protected / h'880700008201692f2f6473742f7376638201682f2f7372632f62708201682f2f7372 632f6270820018281a000f4240', / external_aad / h'85070200004319012c' / payload / ]
[ [2], / targets / 0, / security context TBD / 0, / flags / [ [ / target block #2 / [ / result / 18, / COSE_Sign1 tag / [ <<{ / protected / / alg / 1:-37 / PS256 / }>>, { / unprotected / / kid / 4:'ExampleRSA' }, null, / payload / h'53d983df0590f529456b661d36f217d722aa88497f04779385a9a786693d 518778a23b912e02e272ea120adf0c1ddf2e08fb5efc54c1f6d36a95054b 745fa47e' / signature / ] ] ] ] ]
This is an example of an encryption with implied recipient (and its direct content encryption key). The provided figures are extended diagnostic notation [RFC8610].¶
This example uses a single shared content encryption key, which is not recommended for normal use. The 256-bit key used is shown below. A random IV is generated for this operation and is indicated in a standard way in the unprotected header.¶
[ { / kty / 1: 4, / symmetric / / kid / 2: 'ExampleCEK', / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999db ae4ce45c' } ]
[ 7, / BP version / 0, / flags / 0, / CRC type / [1, "//dst/svc"], / destination / [1, "//src/bp"], / source / [1, "//src/bp"], / report-to / [0, 40], / timestamp / 1000000 / lifetime / ]
[ 7, / type code - bundle age / 2, / block num / 0, / flags / 0, / CRC type / <<300>> / type-specific-data: age / ]
The external_aad is a concatenation of the encoded primary block and the encoded augmented target block (its block data removed).¶
[ "Encrypt0", / context / h'a10103', / protected / h'880700008201692f2f6473742f7376638201682f2f7372632f62708201682f2f7372 632f6270820018281a000f4240850702000040' / external_aad / ]
[ [2], / targets / 0, / security context TBD / 0, / flags / [ [ / target block #2 / [ / result / 16, / COSE_Encrypt0 tag / [ <<{ / protected / / alg / 1:3 / A256GCM / }>>, { / unprotected / / kid / 4:'ExampleCEK', / iv / 5: h'6f3093eba5d85143c3dc484a' }, null / payload / ] ] ] ] ]
[ 7, / type code - bundle age / 2, / block num / 0, / flags / 0, / CRC type / h'63bb1617fc5076cec266907a7143d28587f04e' / ciphertext / ]
This is an example of an encryption with a random CEK and an explicit key-encryption key (KEK) identified by a Key ID. The provided figures are extended diagnostic notation [RFC8610].¶
The keys used are shown in Figure 17. A random IV is generated for this operation and is indicated in a standard way in the unprotected header of Figure 21.¶
[ { / kty / 1: 4, / symmetric / / kid / 2: 'ExampleKEK', / k / -1: h'0e8a982b921d1086241798032fedc1f883eab72e4e43bb2d11cfae38 ad7a972e' }, { / kty / 1: 4, / symmetric / / kid / 2: 'ExampleCEK', / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999db ae4ce45c' } ]
[ 7, / BP version / 0, / flags / 0, / CRC type / [1, "//dst/svc"], / destination / [1, "//src/bp"], / source / [1, "//src/bp"], / report-to / [0, 40], / timestamp / 1000000 / lifetime / ]
[ 7, / type code - bundle age / 2, / block num / 0, / flags / 0, / CRC type / <<300>> / type-specific-data: age / ]
The external_aad is a concatenation of the encoded primary block and the encoded augmented target block (its block data removed).¶
The CEK and content plaintext are the same here as in Figure 14 but the context text is different.¶
[ "Encrypt", / context / h'a10103', / protected / h'880700008201692f2f6473742f7376638201682f2f7372632f62708201682f2f7372 632f6270820018281a000f4240850702000040' / external_aad / ]
[ [2], / targets / 0, / security context TBD / 0, / flags / [ [ / target block #2 / [ / result / 96, / COSE_Encrypt tag / [ <<{ / protected / / alg / 1:3 / A256GCM / }>>, { / unprotected / / iv / 5: h'6f3093eba5d85143c3dc484a' }, null, / payload / [ [ / recipient / h'', / protected / { / unprotected / / alg / 1:-5, / A256KW / / kid / 4:'ExampleKEK' }, h'917f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26d403 a6331159e3d691a708e9984d', / key-wrapped / [] / no more layers / ] ] ] ] ] ] ]
Although the same CEK is used in this example as the Encrypt0 example, the block ciphertext is different than Figure 16 because the Enc_structure (used as AAD) is different.¶
[ 7, / type code - bundle age / 2, / block num / 0, / flags / 0, / CRC type / h'63bb160aa1804f936570b982bf7c396694e574' / ciphertext / ]