idnits 2.17.1
draft-bsipos-dtn-bpsec-cose-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 15 instances of too long lines in the document, the longest
one being 3 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (14 November 2020) is 1257 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '0' on line 1024
-- Looks like a reference, but probably isn't: '40' on line 1024
-- Looks like a reference, but probably isn't: '2' on line 1056
== Unused Reference: 'RFC8551' is defined on line 637, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-BUNDLE'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-COSE'
** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053)
== Outdated reference: A later version (-27) exists of
draft-ietf-dtn-bpsec-22
== Outdated reference: A later version (-28) exists of
draft-ietf-dtn-tcpclv4-22
== Outdated reference: A later version (-09) exists of
draft-ietf-cose-x509-07
== Outdated reference: A later version (-31) exists of
draft-ietf-dtn-bpbis-26
== Outdated reference: A later version (-02) exists of
draft-ietf-dtn-bpsec-interop-sc-01
Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Delay-Tolerant Networking B. Sipos
3 Internet-Draft RKF Engineering
4 Intended status: Standards Track 14 November 2020
5 Expires: 18 May 2021
7 DTN Bundle Protocol Security COSE Security Contexts
8 draft-bsipos-dtn-bpsec-cose-03
10 Abstract
12 This document defines a security context suitable for using CBOR
13 Object Signing and Encryption (COSE) algorithms within Bundle
14 Protocol Security (BPSec) integrity and confidentiality blocks. A
15 profile of COSE is also defined for BPSec interoperation.
17 Status of This Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at https://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on 18 May 2021.
34 Copyright Notice
36 Copyright (c) 2020 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents (https://trustee.ietf.org/
41 license-info) in effect on the date of publication of this document.
42 Please review these documents carefully, as they describe your rights
43 and restrictions with respect to this document. Code Components
44 extracted from this document must include Simplified BSD License text
45 as described in Section 4.e of the Trust Legal Provisions and are
46 provided without warranty as described in the Simplified BSD License.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
51 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
52 1.2. PKIX Environments and CA Policy . . . . . . . . . . . . . 3
53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
54 3. BPSec Security Context . . . . . . . . . . . . . . . . . . . 4
55 3.1. COSE Security Parameters . . . . . . . . . . . . . . . . 4
56 3.2. COSE Integrity . . . . . . . . . . . . . . . . . . . . . 5
57 3.3. COSE Confidentiality . . . . . . . . . . . . . . . . . . 6
58 4. COSE Profile for BPSec . . . . . . . . . . . . . . . . . . . 7
59 4.1. COSE Messages . . . . . . . . . . . . . . . . . . . . . . 7
60 4.2. Interoperability Algorithms . . . . . . . . . . . . . . . 8
61 4.3. Asymmetric Key Types and Identifiers . . . . . . . . . . 9
62 4.3.1. PKIX Certificates . . . . . . . . . . . . . . . . . . 10
63 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
65 6.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 11
66 6.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 12
67 6.3. Threat: Unidentifiable Key . . . . . . . . . . . . . . . 12
68 6.4. Threat: Non-Trusted Public Key . . . . . . . . . . . . . 12
69 6.5. Threat: Passive Leak of Key Material . . . . . . . . . . 13
70 6.6. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 13
71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
72 7.1. BPSec Security Contexts . . . . . . . . . . . . . . . . . 13
73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
75 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
76 9.2. Informative References . . . . . . . . . . . . . . . . . 15
77 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16
78 A.1. Symmetric Key COSE_Mac0 . . . . . . . . . . . . . . . . . 16
79 A.2. RSA Keypair COSE_Sign1 . . . . . . . . . . . . . . . . . 18
80 A.3. Symmetric Key COSE_Encrypt0 . . . . . . . . . . . . . . . 20
81 A.4. Symmetric KEK COSE_Encrypt . . . . . . . . . . . . . . . 22
82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
84 1. Introduction
86 The Bundle Protocol Security (BPSec) Specification
87 [I-D.ietf-dtn-bpsec] defines structure and encoding for Block
88 Integrity Block (BIB) and Block Confidentiality Block (BCB) types but
89 does not specify any security contexts to be used by either of the
90 security block types. The CBOR Object Signing and Encryption (COSE)
91 specification [RFC8152] defines a structure, encoding, and algorithms
92 to use for cryptographic signing and encryption.
94 This document describes how to use the algorithms and encodings of
95 COSE within BPSec blocks to apply those algorithms to Bundle security
96 in Section 3. A bare minimum of interoperability algorithms and
97 algorithm parameters is specified by this document in Section 4. The
98 focus of the recommended algorithms is to allow BPSec to be used in a
99 Public Key Infrastructure (PKI) as described in Section 1.2.
101 Examples of specific uses are provided in Appendix A to aid in
102 implementation support of the interoperability algorithms.
104 1.1. Scope
106 This document describes a profile of COSE which is tailored for use
107 in BPSec and a method of including full COSE messages within BPSec
108 security blocks. This document does not address:
110 * Policies or mechanisms for issuing Public Key Infrastructure Using
111 X.509 (PKIX) certificates; provisioning, deploying, or accessing
112 certificates and private keys; deploying or accessing certificate
113 revocation lists (CRLs); or configuring security parameters on an
114 individual entity or across a network.
116 * Uses of COSE beyond the profile defined in this document.
118 * How those COSE algorithms are intended to be used within a larger
119 security context. Many header parameters used by COSE (e.g., key
120 identifiers) depend on the network environment and security policy
121 related to that environment.
123 1.2. PKIX Environments and CA Policy
125 This specification gives requirements about how to use PKIX
126 certificates issued by a Certificate Authority (CA), but does not
127 define any mechanisms for how those certificates come to be.
129 To support the PKIX uses defined in this document, the CA(s) issuing
130 certificates for BP nodes are aware of the end use of the
131 certificate, have a mechanism for verifying ownership of a Node ID,
132 and are issuing certificates directly for that Node ID. BPSec
133 security acceptors authenticate the Node ID of security sources when
134 verifying integrity using a public key provided by a PKIX certificate
135 (see Section 4.3.1).
137 2. Requirements Language
139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
141 "OPTIONAL" in this document are to be interpreted as described in BCP
142 14 [RFC2119] [RFC8174] when, and only when, they appear in all
143 capitals, as shown here.
145 3. BPSec Security Context
147 This document specifies a single security context for use in both
148 BPSec integrity and confidentiality blocks. This is done to save
149 code points allocated to this specification and to simplify the
150 encoding of COSE-in-BPSec; the BPSec block type uniquely defines the
151 acceptable parameters and COSE messages which can be present.
153 The COSE security context SHALL have the Security Context ID
154 specified in Section 7.1.
156 The COSE security context has parameters to carry public key-related
157 information, with code points are defined in Section 3.1, and results
158 to carry COSE messages, with code points defined in Section 3.2 and
159 Section 3.3. For Result ID values used to identify COSE messages,
160 these code points are also identical to the existing COSE message-
161 marking tags in Section 2 of [RFC8152]. This avoids the need for
162 value-mapping between code points of the two registries.
164 When embedding COSE messages, the CBOR structure SHALL be directly
165 included within the abstract security block (ASB) CBOR structure.
166 There is no use of embedded encoded CBOR (e.g. CBOR encoded as a
167 byte string) in this specification.
169 When embedding COSE messages, the CBOR-tagged form SHALL NOT be used.
170 The Result ID values already provide the same information as the COSE
171 tags (using the same code points).
173 3.1. COSE Security Parameters
175 Each COSE context parameter value SHALL consist of the COSE structure
176 indicated by Table 1 in its decoded (CBOR item) form. Each security
177 block MAY contain any number of each parameter type. See Section 4.3
178 for a definition of how the aggregate of all security parameters
179 apply to each security result.
181 Implementations capable of handling asymmetric-keyed algorithms
182 SHOULD support the public key handling parameters of Table 1. COSE
183 security parameters SHALL NOT contain any private key material. The
184 security parameters are all stored in the bundle as plaintext and are
185 visible to any bundle handlers.
187 +==============+======================+======================+
188 | Parameter ID | Parameter Structure | Reference |
189 +==============+======================+======================+
190 | 1 | COSE_Key | [RFC8152] |
191 +--------------+----------------------+----------------------+
192 | 2 | COSE_KeySet | [RFC8152] |
193 +--------------+----------------------+----------------------+
194 | 3 | COSE_X509 as x5chain | [I-D.ietf-cose-x509] |
195 +--------------+----------------------+----------------------+
196 | 4 | COSE_X509 as x5bag | [I-D.ietf-cose-x509] |
197 +--------------+----------------------+----------------------+
199 Table 1: COSE Security Parameters
201 3.2. COSE Integrity
203 When used within a Block Integrity Block, COSE context SHALL allow
204 all Parameter IDs defined in Table 1. When used within a Block
205 Integrity Block, COSE context SHALL allow only the Result IDs from
206 Table 2. Each integrity result value SHALL consist of the COSE
207 message indicated by Table 2 in its decoded form.
209 +===========+==================+===========+
210 | Result ID | Result Structure | Reference |
211 +===========+==================+===========+
212 | 97 | COSE_Mac | [RFC8152] |
213 +-----------+------------------+-----------+
214 | 17 | COSE_Mac0 | [RFC8152] |
215 +-----------+------------------+-----------+
216 | 98 | COSE_Sign | [RFC8152] |
217 +-----------+------------------+-----------+
218 | 18 | COSE_Sign1 | [RFC8152] |
219 +-----------+------------------+-----------+
221 Table 2: COSE Integrity Results
223 Each integrity result SHALL use the "detached" payload form with nil
224 payload value. The integrity result for COSE_Mac and COSE_Mac0
225 messages are computed by the procedure in Section 6.3 of [RFC8152].
226 The integrity result for COSE_Sign and COSE_Sign1 messages are
227 computed by the procedure in Section 4.4 of [RFC8152].
229 [NOTE: This differs from base BPSec in that the entire block and the
230 bundle primary is signed] The COSE "payload" used to generate a
231 signature or MAC result SHALL be the canonically serialized target
232 block, including the canonical block array structure. The COSE
233 "protected attributes from the application" used to generate a
234 signature or MAC result SHALL be either:
236 For a primary block target: An empty byte string.
238 For a canonical block target: The canonically serialized primary
239 block of the bundle.
241 3.3. COSE Confidentiality
243 When used within a Block Confidentiality Block, COSE context SHALL
244 allow all Parameter IDs defined in Table 1. When used within a Block
245 Confidentiality Block, COSE context SHALL allow only the Result IDs
246 from Table 3. Each confidentiality result value SHALL consist of the
247 COSE message indicated by Table 3 in its decoded form.
249 +===========+==================+===========+
250 | Result ID | Result Structure | Reference |
251 +===========+==================+===========+
252 | 96 | COSE_Encrypt | [RFC8152] |
253 +-----------+------------------+-----------+
254 | 16 | COSE_Encrypt0 | [RFC8152] |
255 +-----------+------------------+-----------+
257 Table 3: COSE Confidentiality Results
259 Only algorithms which support Authenticated Encryption with
260 Authenticated Data (AEAD) SHALL be usable in the first (content)
261 layer of a confidentiality result. Because COSE encryption with AEAD
262 appends the authentication tag with the ciphertext, the size of the
263 block-type-specific-data will grow after an encryption operation.
265 Each confidentiality result SHALL use the "detached" payload form
266 with nil payload value. The COSE plaintext and ciphertext correspond
267 exactly with the target block-type-specific-data. The
268 confidentiality result for COSE_Encrypt and COSE_Encrypt0 messages
269 are computed by the procedure in Section 5.3 of [RFC8152].
271 [NOTE: This differs from base BPSec in that AAD from the block and
272 the bundle primary is used] The COSE "plaintext" used to generate an
273 encrypt result SHALL be the block-type-specific-data of the target
274 block, the decoded byte string itself (not including the encoded CBOR
275 item header). The COSE "protected attributes from the application"
276 used to generate an encrypt result SHALL be the concatenation of the
277 following:
279 1. The canonically serialized primary block of the bundle.
281 2. The canonically serialized augmented target block, which has its
282 block-type-specific-data substituted with an empty byte string.
284 4. COSE Profile for BPSec
286 This section contains requirements which apply to the use of COSE
287 within BPSec across any security context use.
289 4.1. COSE Messages
291 When generating a BPSec result, security sources SHALL use encode
292 COSE labels with a uint value. When processing a BPSec result,
293 security acceptors MAY handle COSE labels with with a tstr value.
295 When used in a BPSec result, each COSE message SHALL contain an
296 explicit algorithm identifier in the lower (content) layers. When
297 available and not implied by the bundle source, a COSE message SHALL
298 contain a key identifier in the highest (recipient) layer. See
299 Section 4.3 for specifics about asymmetric key identifiers. When a
300 key identifier is not available, BPSec acceptors SHALL use the
301 Security Source (if available) and the Bundle Source to imply which
302 keys can be used for security operations. Using implied keys has an
303 interoperability risk, see Section 6.3 for details. A BPSec security
304 operation always occurs within the context of the immutable primary
305 block with its parameters (specifically the Source Node ID) and the
306 security block with its optional Security Source.
308 The algorithms required by this profile focuses on networks using
309 shared symmetric-keys, with recommended algorithms for Elliptic Curve
310 (EC) keypairs and RSA keypairs. The focus of this profile is to
311 enable interoperation between security sources and acceptors on an
312 open network, where more explicit COSE parameters make it easier for
313 BPSec acceptors to avoid assumptions and avoid out-of-band
314 parameters. The requirements of this profile still allow the use of
315 potentially not-easily-interoperable algorithms and message/recipient
316 configurations for use by private networks, where message size is
317 more important than explicit COSE parameters.
319 4.2. Interoperability Algorithms
321 [NOTE: The required list is identical to the
322 [I-D.ietf-dtn-bpsec-interop-sc] list.] The set of integrity
323 algorithms needed for interoperability is listed here. The full set
324 of COSE algorithms available is managed at [IANA-COSE].
326 Implementations conforming to this specification SHALL support the
327 symmetric keyed and key-encryption algorithms of Table 4.
328 Implementations capable of doing so SHOULD support the asymmetric
329 keyed and key-encryption algorithms of Table 4.
331 +=================+============+============+======+================+
332 | BPSec Block | COSE | Name | Code | Implementation |
333 | | Layer | | | Requirements |
334 +=================+============+============+======+================+
335 | Integrity | 1 | HMAC | 5 | Required |
336 | | | 256/256 | | |
337 +-----------------+------------+------------+------+----------------+
338 | Integrity | 1 | ES256 | -7 | Recommended |
339 +-----------------+------------+------------+------+----------------+
340 | Integrity | 1 | EdDSA | -8 | Recommended |
341 +-----------------+------------+------------+------+----------------+
342 | Integrity | 1 | PS256 | -37 | Recommended |
343 +-----------------+------------+------------+------+----------------+
344 | Confidentiality | 1 | A256GCM | 3 | Required |
345 +-----------------+------------+------------+------+----------------+
346 | Integrity or | 2 | A256KW | -5 | Required |
347 | Confidentiality | | | | |
348 +-----------------+------------+------------+------+----------------+
349 | Integrity or | 2 | ECDH-ES + | -31 | Recommended |
350 | Confidentiality | | A256KW | | |
351 +-----------------+------------+------------+------+----------------+
352 | Integrity or | 2 | RSAES-OAEP | -41 | Recommended |
353 | Confidentiality | | w/ SHA-256 | | |
354 +-----------------+------------+------------+------+----------------+
356 Table 4: Interoperability Algorithms
358 The following are recommended key and recipient uses within COSE/
359 BPSec:
361 Symmetric Key Integrity: When generating a BIB result from a
362 symmetric key, implementations SHOULD use either a COSE_Mac0 or a
363 COSE_Mac using the private key directly. When a COSE_Mac is used
364 with a direct key, the recipient layer SHALL include a key
365 identifier.
367 EC Keypair Integrity: When generating a BIB result from an EC
368 keypair, implementations SHOULD use either a COSE_Sign1 or a
369 COSE_Sign using the private key directly or a COSE_Mac from a
370 symmetric key with a layer-2 encryption of the symmetric key.
371 When a COSE_Sign or COSE_Mac is used with EC keypair, the
372 recipient layer SHALL include a public key identifier (see
373 Section 4.3).
375 RSA Keypair Integrity: When generating a BIB result from an RSA
376 keypair, implementations SHOULD use either a COSE_Sign1 or a
377 COSE_Sign using the private key directly or a COSE_Mac from a
378 symmetric key with a layer-2 key-wrap of the symmetric key. When
379 a COSE_Sign or COSE_Mac is used with RSA keypair, the recipient
380 layer SHALL include a public key identifier (see Section 4.3).
381 When a COSE_Sign or COSE_Sign1 is used with RSA keypair, the
382 signature uses a maximum-length PSS salt in accordance with
383 [RFC8230].
385 Symmetric Key Confidentiality: When generating a BCB result from an
386 symmetric key, implementations SHOULD use a COSE_Encrypt message
387 with a recipient containing a key-wrapped CEK. When generating a
388 BCB result from a symmetric key, implementations SHOULD NOT use
389 COSE_Encrypt0 or COSE_Encrypt with direct content encryption key
390 (CEK). Doing so risks key overuse and the vulnerabilities
391 associated with large amount of ciphertext from the same key.
393 EC Keypair Confidentiality: When generating a BCB result from an EC
394 keypair, implementations SHOULD use a COSE_Encrypt message with a
395 recipient containing a key-wrapped CEK.
397 RSA Keypair Confidentiality: When generating a BCB result from an
398 RSA keypair, implementations SHOULD use a COSE_Encrypt message
399 with a recipient containing a key-wrapped CEK.
401 4.3. Asymmetric Key Types and Identifiers
403 This section applies when a BIB uses a public key for verification,
404 or when a BCB uses a public key for encryption. When using
405 asymmetric keyed algorithms, the security source SHALL include a
406 public key identifier as a recipient header. The public key
407 identifier SHALL be either a "kid" [RFC8152], an "x5t"
408 [I-D.ietf-cose-x509], or an equivalent identifier.
410 When a BIB result contains a "kid" identifier, the security source
411 SHOULD include an appropriate COSE public key in the security
412 parameters. When BIB result contains a "x5t" identifier, the
413 security source SHOULD include an appropriate PKIX certificate chain
414 in the security parameters. For a BIB, if all potential security
415 acceptors are known to possess related public key and/or certificate
416 data then the public key parameters can be omitted. Risks of not
417 including related data are described in Section 6.3 and Section 6.4.
419 When present, public keys and certificates SHOULD be included as ASB
420 parameters rather than within ASB results. This provides size
421 efficiency when multiple security results are present because they
422 will all be from the same security source and likely share the same
423 public key material. Security acceptors SHALL still process public
424 keys or certificates present in a result as applying to that
425 individual result.
427 Security acceptors SHALL aggregate all public keys from all
428 parameters within a single BIB or BCB, independent of encoded type or
429 order of parameters. Because each context contains a single set of
430 security parameters which apply to all results in the same context,
431 security acceptors SHALL treat all public keys as being related to
432 the security source itself and potentially applying to every result.
434 4.3.1. PKIX Certificates
436 When PKIX certificates are present as parameters, security sources
437 SHOULD include the entire certification chain to the root CA. When
438 PKIX certificates are used by security acceptors and the end-entity
439 certificate is not explicitly trusted (i.e. pinned), the security
440 acceptor SHALL perform the certification path validation of [RFC5280]
441 up to one or more trusted CA certificates. Leaving out part of the
442 certification chain can cause the security acceptor to fail to
443 validate a BIB if the left-out certificates are unknown to the
444 acceptor (see Section 6.4).
446 When a PKIX certificate is referenced by a BIB result, security
447 acceptors SHALL authenticate either the Security Source (if present)
448 or the Bundle Source (as the implied security source) against any
449 NODE-ID contained in the referenced certificate as defined in
450 [I-D.ietf-dtn-tcpclv4]. If the Security Source authentication result
451 is Failure or if the result is Absent and security policy requires an
452 authenticated Node ID, the acceptor SHALL treat the security result
453 as invalid.
455 All certificates used by COSE security SHALL include a key usage
456 extension in accordance with [RFC5280]. The key usage extension is
457 required to be supported by CAs conforming to the profile of
458 [RFC5280]. A security acceptor SHALL limit the use of PKIX
459 certificates based on the key usage extension.
461 5. Implementation Status
463 [NOTE to the RFC Editor: please remove this section before
464 publication, as well as the reference to [RFC7942] and
465 [github-dtn-bpsec-cose].]
467 This section records the status of known implementations of the
468 protocol defined by this specification at the time of posting of this
469 Internet-Draft, and is based on a proposal described in [RFC7942].
470 The description of implementations in this section is intended to
471 assist the IETF in its decision processes in progressing drafts to
472 RFCs. Please note that the listing of any individual implementation
473 here does not imply endorsement by the IETF. Furthermore, no effort
474 has been spent to verify the information presented here that was
475 supplied by IETF contributors. This is not intended as, and must not
476 be construed to be, a catalog of available implementations or their
477 features. Readers are advised to note that other implementations can
478 exist.
480 An example implementation of COSE over Blocks has been created as a
481 GitHub project [github-dtn-bpsec-cose] and is intended to use as a
482 proof-of-concept and as a possible source of interoperability
483 testing. This example implementation only handles CBOR encoding/
484 decoding and cryptographic functions, it does not construct actual
485 BIB or BCB and does not integrate with a BP Agent.
487 6. Security Considerations
489 This section separates security considerations into threat categories
490 based on guidance of BCP 72 [RFC3552].
492 All of the security considerations of the underlying BPSec
493 [I-D.ietf-dtn-bpsec] apply to these new security contexts.
495 6.1. Threat: BPSec Block Replay
497 The bundle's primary block contains fields which uniquely identify a
498 bundle: the Source Node ID, Creation Timestamp, and fragment
499 parameters (see Section 4.2.2 of [I-D.ietf-dtn-bpbis]). These same
500 fields are used to correlate Administrative Records with the bundles
501 for which the records were generated. Including the primary block in
502 the additional authenticated data (AAD) for BPSec integrity and
503 confidentiality binds the verification of the secured block to its
504 parent bundle and disallows replay of any block with its BIB or BCB.
506 This profile of COSE limits the encryption algorithms to only AEAD in
507 order to include the context of the encrypted data as AAD. If an
508 agent mistakenly allows the use of non-AEAD encryption when
509 decrypting and verifying a BCB, the possibility of block replay
510 attack is present.
512 6.2. Threat: BP Node Impersonation
514 When certificates are referenced by BIB results it is possible that
515 the certificate does not contain a NODE-ID or does contain one but
516 has a mismatch with the actual security source (see Section 1.2).
517 Having a CA-validated certificate does not alone guarantee the
518 identity of the security source from which the certificate is
519 provided; additional validation procedures in Section 4.3.1 bind the
520 Node ID based on the contents of the certificate.
522 6.3. Threat: Unidentifiable Key
524 The profile in Section 4.2 recommends key identifiers when possible
525 and the parameters in section Section 3.1 allow encoding public keys
526 where available. If the application using a COSE Integrity or COSE
527 Confidentiality context leaves out key identification data (in a COSE
528 recipient structure), the security acceptor for those BPSec blocks
529 only has the primary block available to use when verifying or
530 decrypting the target block. This leads to a situation, identified
531 in BPSec Security Considerations, where a signature is verified to be
532 valid but not from the expected Security Source.
534 Because the key identifier headers are unprotected (see Section 4.3),
535 there is still the possibility that an active attacker removes or
536 alters key identifier(s) in the result. This can cause the security
537 acceptor to not be able to properly verify a valid signature or not
538 use the correct private key to decrypt valid ciphertext.
540 6.4. Threat: Non-Trusted Public Key
542 The profile in Section 4.2 allows the use of PKIX which typically
543 involves end-entity certificates chained up to a trusted root CA.
544 This allows a BIB to contain end-entity certificates not previously
545 known to a security acceptor but still trust the certificate by
546 verifying it up to a trusted CA. In an environment where security
547 acceptors are known to already contain needed root and intermediate
548 CAs there is no need to include those CAs in a proper chain within
549 the security parameters, but this has a risk of an acceptor not
550 actually having one of the needed CAs.
552 Because the security parameters are not included as AAD, there is
553 still the possibility that an active attacker removes or alters
554 certification chain data in the parameters. This can cause the
555 security acceptor to be able to verify a valid signature but not
556 trust the public key used to perform the verification.
558 6.5. Threat: Passive Leak of Key Material
560 It is important that the key requirements of Section 3.1 apply only
561 to public keys and PKIX certificates. Including non-public key
562 material in ASB parameters will expose that material in the bundle
563 data and over the bundle convergence layer during transport.
565 6.6. Threat: Algorithm Vulnerabilities
567 Because this use of COSE leaves the specific algorithms chosen for
568 BIB and BCB use up to the applications securing bundle data, it is
569 important to use only COSE algorithms which are marked as recommended
570 in the IANA registry [IANA-COSE].
572 7. IANA Considerations
574 Registration procedures referred to in this section are defined in
575 [RFC8126].
577 7.1. BPSec Security Contexts
579 Within the "Bundle Protocol" registry [IANA-BUNDLE], the following
580 entry has been added to the "BPSec Security Context Identifiers" sub-
581 registry.
583 +==========+=============+=====================+
584 | Value | Description | Reference |
585 +==========+=============+=====================+
586 | TBD-COSE | COSE | This specification. |
587 +----------+-------------+---------------------+
589 Table 5
591 8. Acknowledgments
593 The interoperability minimum algorithms and parameters are based on
594 the draft [I-D.ietf-dtn-bpsec-interop-sc].
596 9. References
598 9.1. Normative References
600 [IANA-BUNDLE]
601 IANA, "Bundle Protocol",
602 .
604 [IANA-COSE]
605 IANA, "CBOR Object Signing and Encryption (COSE)",
606 .
608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
609 Requirement Levels", BCP 14, RFC 2119,
610 DOI 10.17487/RFC2119, March 1997,
611 .
613 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
614 Housley, R., and W. Polk, "Internet X.509 Public Key
615 Infrastructure Certificate and Certificate Revocation List
616 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
617 .
619 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
620 Writing an IANA Considerations Section in RFCs", BCP 26,
621 RFC 8126, DOI 10.17487/RFC8126, June 2017,
622 .
624 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
625 RFC 8152, DOI 10.17487/RFC8152, July 2017,
626 .
628 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
629 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
630 May 2017, .
632 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
633 and Encryption (COSE) Messages", RFC 8230,
634 DOI 10.17487/RFC8230, September 2017,
635 .
637 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
638 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
639 Message Specification", RFC 8551, DOI 10.17487/RFC8551,
640 April 2019, .
642 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
643 Definition Language (CDDL): A Notational Convention to
644 Express Concise Binary Object Representation (CBOR) and
645 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
646 June 2019, .
648 [I-D.ietf-dtn-bpsec]
649 Birrane, E. and K. McKeever, "Bundle Protocol Security
650 Specification", Work in Progress, Internet-Draft, draft-
651 ietf-dtn-bpsec-22, 10 March 2020,
652 .
654 [I-D.ietf-dtn-tcpclv4]
655 Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
656 Tolerant Networking TCP Convergence Layer Protocol Version
657 4", Work in Progress, Internet-Draft, draft-ietf-dtn-
658 tcpclv4-22, 26 October 2020,
659 .
661 [I-D.ietf-cose-x509]
662 Schaad, J., "CBOR Object Signing and Encryption (COSE):
663 Header parameters for carrying and referencing X.509
664 certificates", Work in Progress, Internet-Draft, draft-
665 ietf-cose-x509-07, 17 September 2020,
666 .
668 9.2. Informative References
670 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
671 Text on Security Considerations", BCP 72, RFC 3552,
672 DOI 10.17487/RFC3552, July 2003,
673 .
675 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
676 Code: The Implementation Status Section", BCP 205,
677 RFC 7942, DOI 10.17487/RFC7942, July 2016,
678 .
680 [I-D.ietf-dtn-bpbis]
681 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
682 Version 7", Work in Progress, Internet-Draft, draft-ietf-
683 dtn-bpbis-26, 28 July 2020,
684 .
686 [I-D.ietf-dtn-bpsec-interop-sc]
687 Birrane, E., "BPSec Interoperability Security Contexts",
688 Work in Progress, Internet-Draft, draft-ietf-dtn-bpsec-
689 interop-sc-01, 4 February 2020,
690 .
693 [github-dtn-bpsec-cose]
694 Sipos, B., "DTN Bundle Protocol Security COSE Security
695 Contexts",
696 .
698 Appendix A. Examples
700 These examples are intended to have the correct structure of COSE
701 security blocks but in some cases use simplified algorithm parameters
702 or smaller key sizes than are required by the actual COSE profile
703 defined in this documents. Each example indicates how it differs
704 from the actual profile if there is a meaningful difference.
706 A.1. Symmetric Key COSE_Mac0
708 This is an example of a MAC with implied recipient (and its key
709 material). The provided figures are extended diagnostic notation
710 [RFC8610].
712 The 256-bit key used is shown below.
714 [
715 {
716 / kty / 1: 4, / symmetric /
717 / kid / 2: 'ExampleMAC',
718 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999db
719 ae4ce45c'
720 }
721 ]
723 Figure 1: Symmetric Key
725 [
726 7, / BP version /
727 0, / flags /
728 0, / CRC type /
729 [1, "//dst/svc"], / destination /
730 [1, "//src/bp"], / source /
731 [1, "//src/bp"], / report-to /
732 [0, 40], / timestamp /
733 1000000 / lifetime /
734 ]
736 Figure 2: Primary block CBOR diagnostic
738 [
739 7, / type code - bundle age /
740 2, / block num /
741 0, / flags /
742 0, / CRC type /
743 <<300>> / type-specific-data: age /
744 ]
746 Figure 3: Target block CBOR diagnostic
748 The external_aad is the encoded primary block. The payload is the
749 encoded target block.
751 [
752 "MAC0", / context /
753 h'a10105', / protected /
754 h'880700008201692f2f6473742f7376638201682f2f7372632f62708201682f2f7372
755 632f6270820018281a000f4240', / external_aad /
756 h'85070200004319012c' / payload /
757 ]
759 Figure 4: MAC_structure CBOR diagnostic
761 [
762 [2], / targets /
763 0, / security context TBD /
764 0, / flags /
765 [
766 [ / target block #2 /
767 [ / result /
768 17, / COSE_Mac0 tag /
769 [
770 <<{ / protected /
771 / alg / 1:5 / HMAC 256//256 /
772 }>>,
773 { / unprotected /
774 / kid / 4:'ExampleMAC'
775 },
776 null, / payload /
777 h'1349a33b41b020e46669b714b53a1b79db458fdef0f0b7a0daebde6baf27
778 7472' / tag /
779 ]
780 ]
781 ]
782 ]
783 ]
785 Figure 5: Abstract Security Block CBOR diagnostic
787 A.2. RSA Keypair COSE_Sign1
789 This is an example of a signature with an explicit signer key ID and
790 signer public key itself (as a COSE_Key). The provided figures are
791 extended diagnostic notation [RFC8610].
793 The only differences between this example and a use of a PKIX public
794 key certificate are: the parameters would have an x5chain parameter
795 instead of a COSE_Key type, and the signature recipient would
796 reference an "x5t" value instead of a "kid" value. Neither of these
797 is a change to a protected header so, given the same private key,
798 there would be no change to the signature itself.
800 The 512-bit private key used is below. It is not supposed to be a
801 secure configuration, only intended to explain the procedure. This
802 signature uses zero-length salt for deterministic output, which
803 differs from the parameter specified by [RFC8230] and is not
804 recommended for normal use.
806 [
807 { / signing private key /
808 / kty / 1: 3, / RSA /
809 / kid / 2: 'ExampleRSA',
810 / n / -1: b64'3bUZ1LR9oBiBpx6lGZuvtMBPTAS5qGOsF8A7QODUzl3fs71PH0e9nD
811 Y4RwurZZO9_QqNrUlamp2gmbXsuCGE-Q',
812 / e / -2: b64'AQAB',
813 / d / -3: b64'yCQmj2foSFAXKuB1Nmre8RLyArP5TdO8lSxJ0UWllixmFRoso_2jHI
814 jGXci8rmJLSgCxbSeojtoxwGg-bFmlAQ',
815 / p / -4: b64'7snebs70tMJ67A1qA4Yk5ujvjyaDEIsfch_fRwVIVik',
816 / q / -5: b64'7bAM_t782esDusNKAzr5EQaa3wjTQ2CUXBKEFSLgclE',
817 / dP / -6: b64'Iiay7kwhCV0rMWl1uQ1NZ8z2vhV29z2-gJb4WvLxdok',
818 / dQ / -7: b64'bC7WK2dJBNKv9uCOHlxIItSzxtIYfjFGNYYD8i7Wo5E',
819 / qInv / -8: b64'6efvn6dOADFQJxNLqjRJyE5E1m_dYQEvCI2mAqixshA'
820 }
821 ]
823 Figure 6: Private Keys
825 [
826 7, / BP version /
827 0, / flags /
828 0, / CRC type /
829 [1, "//dst/svc"], / destination /
830 [1, "//src/bp"], / source /
831 [1, "//src/bp"], / report-to /
832 [0, 40], / timestamp /
833 1000000 / lifetime /
834 ]
835 Figure 7: Primary block CBOR diagnostic
837 [
838 7, / type code - bundle age /
839 2, / block num /
840 0, / flags /
841 0, / CRC type /
842 <<300>> / type-specific-data: age /
843 ]
845 Figure 8: Target block CBOR diagnostic
847 The external_aad is the encoded primary block. The payload is the
848 encoded target block.
850 [
851 "Signature1", / context /
852 h'a1013824', / protected /
853 h'880700008201692f2f6473742f7376638201682f2f7372632f62708201682f2f7372
854 632f6270820018281a000f4240', / external_aad /
855 h'85070200004319012c' / payload /
856 ]
858 Figure 9: Sig_structure CBOR diagnostic
860 [
861 [2], / targets /
862 0, / security context TBD /
863 1, / flags /
864 [ / parameters /
865 [
866 101, / COSE key /
867 { / public key /
868 / kty / 1: 3, / RSA /
869 / kid / 2: 'ExampleRSA',
870 / n / -1: b64'3bUZ1LR9oBiBpx6lGZuvtMBPTAS5qGOsF8A7QODUzl3fs71PH0
871 e9nDY4RwurZZO9_QqNrUlamp2gmbXsuCGE-Q',
872 / e / -2: b64'AQAB',
873 }
874 ]
875 ],
876 [
877 [ / target block #2 /
878 [ / result /
879 18, / COSE_Sign1 tag /
880 [
881 <<{ / protected /
882 / alg / 1:-37 / PS256 /
883 }>>,
884 { / unprotected /
885 / kid / 4:'ExampleRSA'
886 },
887 null, / payload /
888 h'53d983df0590f529456b661d36f217d722aa88497f04779385a9a786693d
889 518778a23b912e02e272ea120adf0c1ddf2e08fb5efc54c1f6d36a95054b
890 745fa47e' / signature /
891 ]
892 ]
893 ]
894 ]
895 ]
897 Figure 10: Abstract Security Block CBOR diagnostic
899 A.3. Symmetric Key COSE_Encrypt0
901 This is an example of an encryption with implied recipient (and its
902 direct content encryption key). The provided figures are extended
903 diagnostic notation [RFC8610].
905 This example uses a single shared content encryption key, which is
906 not recommended for normal use. The 256-bit key used is shown below.
907 A random IV is generated for this operation and is indicated in a
908 standard way in the unprotected header.
910 [
911 {
912 / kty / 1: 4, / symmetric /
913 / kid / 2: 'ExampleCEK',
914 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999db
915 ae4ce45c'
916 }
917 ]
919 Figure 11: Symmetric Keys
921 [
922 7, / BP version /
923 0, / flags /
924 0, / CRC type /
925 [1, "//dst/svc"], / destination /
926 [1, "//src/bp"], / source /
927 [1, "//src/bp"], / report-to /
928 [0, 40], / timestamp /
929 1000000 / lifetime /
930 ]
932 Figure 12: Primary block CBOR diagnostic
934 [
935 7, / type code - bundle age /
936 2, / block num /
937 0, / flags /
938 0, / CRC type /
939 <<300>> / type-specific-data: age /
940 ]
942 Figure 13: Initial Target block CBOR diagnostic
944 The external_aad is a concatenation of the encoded primary block and
945 the encoded augmented target block (its block data removed).
947 [
948 "Encrypt0", / context /
949 h'a10103', / protected /
950 h'880700008201692f2f6473742f7376638201682f2f7372632f62708201682f2f7372
951 632f6270820018281a000f4240850702000040' / external_aad /
952 ]
953 Figure 14: Enc_structure CBOR diagnostic
955 [
956 [2], / targets /
957 0, / security context TBD /
958 0, / flags /
959 [
960 [ / target block #2 /
961 [ / result /
962 16, / COSE_Encrypt0 tag /
963 [
964 <<{ / protected /
965 / alg / 1:3 / A256GCM /
966 }>>,
967 { / unprotected /
968 / kid / 4:'ExampleCEK',
969 / iv / 5: h'6f3093eba5d85143c3dc484a'
970 },
971 null / payload /
972 ]
973 ]
974 ]
975 ]
976 ]
978 Figure 15: Abstract Security Block CBOR diagnostic
980 [
981 7, / type code - bundle age /
982 2, / block num /
983 0, / flags /
984 0, / CRC type /
985 h'63bb1617fc5076cec266907a7143d28587f04e' / ciphertext /
986 ]
988 Figure 16: Encrypted Target block CBOR diagnostic
990 A.4. Symmetric KEK COSE_Encrypt
992 This is an example of an encryption with a random CEK and an explicit
993 key-encryption key (KEK) identified by a Key ID. The provided
994 figures are extended diagnostic notation [RFC8610].
996 The keys used are shown in Figure 17. A random IV is generated for
997 this operation and is indicated in a standard way in the unprotected
998 header of Figure 21.
1000 [
1001 {
1002 / kty / 1: 4, / symmetric /
1003 / kid / 2: 'ExampleKEK',
1004 / k / -1: h'0e8a982b921d1086241798032fedc1f883eab72e4e43bb2d11cfae38
1005 ad7a972e'
1006 },
1007 {
1008 / kty / 1: 4, / symmetric /
1009 / kid / 2: 'ExampleCEK',
1010 / k / -1: h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999db
1011 ae4ce45c'
1012 }
1013 ]
1015 Figure 17: Symmetric Keys
1017 [
1018 7, / BP version /
1019 0, / flags /
1020 0, / CRC type /
1021 [1, "//dst/svc"], / destination /
1022 [1, "//src/bp"], / source /
1023 [1, "//src/bp"], / report-to /
1024 [0, 40], / timestamp /
1025 1000000 / lifetime /
1026 ]
1028 Figure 18: Primary block CBOR diagnostic
1030 [
1031 7, / type code - bundle age /
1032 2, / block num /
1033 0, / flags /
1034 0, / CRC type /
1035 <<300>> / type-specific-data: age /
1036 ]
1038 Figure 19: Initial Target block CBOR diagnostic
1040 The external_aad is a concatenation of the encoded primary block and
1041 the encoded augmented target block (its block data removed).
1043 The CEK and content plaintext are the same here as in Figure 14 but
1044 the context text is different.
1046 [
1047 "Encrypt", / context /
1048 h'a10103', / protected /
1049 h'880700008201692f2f6473742f7376638201682f2f7372632f62708201682f2f7372
1050 632f6270820018281a000f4240850702000040' / external_aad /
1051 ]
1053 Figure 20: Enc_structure CBOR diagnostic
1055 [
1056 [2], / targets /
1057 0, / security context TBD /
1058 0, / flags /
1059 [
1060 [ / target block #2 /
1061 [ / result /
1062 96, / COSE_Encrypt tag /
1063 [
1064 <<{ / protected /
1065 / alg / 1:3 / A256GCM /
1066 }>>,
1067 { / unprotected /
1068 / iv / 5: h'6f3093eba5d85143c3dc484a'
1069 },
1070 null, / payload /
1071 [
1072 [ / recipient /
1073 h'', / protected /
1074 { / unprotected /
1075 / alg / 1:-5, / A256KW /
1076 / kid / 4:'ExampleKEK'
1077 },
1078 h'917f2045e1169502756252bf119a94cdac6a9d8944245b5a9a26d403
1079 a6331159e3d691a708e9984d', / key-wrapped /
1080 [] / no more layers /
1081 ]
1082 ]
1083 ]
1084 ]
1085 ]
1086 ]
1087 ]
1089 Figure 21: Abstract Security Block CBOR diagnostic
1091 Although the same CEK is used in this example as the Encrypt0
1092 example, the block ciphertext is different than Figure 16 because the
1093 Enc_structure (used as AAD) is different.
1095 [
1096 7, / type code - bundle age /
1097 2, / block num /
1098 0, / flags /
1099 0, / CRC type /
1100 h'63bb160aa1804f936570b982bf7c396694e574' / ciphertext /
1101 ]
1103 Figure 22: Encrypted Target block CBOR diagnostic
1105 Author's Address
1107 Brian Sipos
1108 RKF Engineering Solutions, LLC
1109 7500 Old Georgetown Road
1110 Suite 1275
1111 Bethesda, MD 20814-6198
1112 United States of America
1114 Email: BSipos@rkf-eng.com