idnits 2.17.1
draft-bsipos-dtn-bpsec-cose-00.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 is 1 instance of too long lines in the document, the longest one
being 13 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 (June 24, 2020) is 1393 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 445
-- Looks like a reference, but probably isn't: '40' on line 445
-- Looks like a reference, but probably isn't: '2' on line 471
== Outdated reference: A later version (-27) exists of
draft-ietf-dtn-bpsec-22
-- 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 (-31) exists of
draft-ietf-dtn-bpbis-25
== Outdated reference: A later version (-02) exists of
draft-ietf-dtn-bpsec-interop-sc-01
-- Obsolete informational reference (is this intentional?): RFC 7049
(Obsoleted by RFC 8949)
Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 June 24, 2020
5 Expires: December 26, 2020
7 DTN Bundle Protocol Security COSE Security Contexts
8 draft-bsipos-dtn-bpsec-cose-00
10 Abstract
12 This document defines an integrity security context and a
13 confidentiality security context suitable for using CBOR Object
14 Signing and Encryption (COSE) algorithms within Bundle Protocol
15 Security (BPSec) blocks.
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 December 26, 2020.
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
41 (https://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
53 3. BPSec Security Contexts . . . . . . . . . . . . . . . . . . . 3
54 3.1. COSE Integrity Context . . . . . . . . . . . . . . . . . 3
55 3.1.1. Interoperability Algorithms . . . . . . . . . . . . . 4
56 3.2. COSE Confidentiality Context . . . . . . . . . . . . . . 4
57 3.2.1. Interoperability Algorithms . . . . . . . . . . . . . 5
58 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 5
59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
60 5.1. Threat: BPSec Block Replay . . . . . . . . . . . . . . . 6
61 5.2. Threat: Algorithm Vulnerabilities . . . . . . . . . . . . 6
62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
63 6.1. BPSec Security Contexts . . . . . . . . . . . . . . . . . 6
64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
67 8.2. Informative References . . . . . . . . . . . . . . . . . 8
68 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8
69 A.1. COSE_Mac0 . . . . . . . . . . . . . . . . . . . . . . . . 8
70 A.2. COSE_Encrypt0 . . . . . . . . . . . . . . . . . . . . . . 10
71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
73 1. Introduction
75 The Bundle Protocol Security (BPSec) Specification
76 [I-D.ietf-dtn-bpsec] defines structure and encoding for Block
77 Integrity Block (BIB) and Block Confidentiality Block (BCB) types but
78 does not specify any security contexts to be used by either of the
79 security block types. The CBOR Object Signing and Encryption (COSE)
80 specification [RFC8152] defines a structure, encoding, and algorithms
81 to use for cryptographic signing and encryption.
83 This document describes how to use the algorithms and encodings of
84 COSE within BPSec blocks to apply those algorithms to Bundle
85 security. A bare minimum of interoperability algorithms and
86 algorithm parameters is specified by this document.
88 This document does not address how those COSE algorithms are intended
89 to be used within a larger security context.
91 2. Requirements Language
93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
95 "OPTIONAL" in this document are to be interpreted as described in BCP
96 14 [RFC2119] [RFC8174] when, and only when, they appear in all
97 capitals, as shown here.
99 3. BPSec Security Contexts
101 Rather than defining a single security context for both integrity and
102 confidentiality blocks, this document specifies two separate security
103 contexts which are analogous to the two BPSec block types. Each
104 security context allows a specific set of BPSec Result IDs.
106 The existing COSE structure-marking tags in Section 2 of [RFC8152]
107 SHALL be used as BPSec Result ID values for all COSE security
108 contexts (see Table 1 and Table 2). This avoids the need for value-
109 mapping between code points of the two registries.
111 When embedding COSE structures, the CBOR-tagged form SHALL NOT be
112 used. The Result ID values already provide the same information as
113 the COSE tags.
115 3.1. COSE Integrity Context
117 The COSE Integrity Context has a Security Context ID of TBD-CI.
119 The integrity context SHALL allow only the Result IDs from Table 1.
120 Each integrity context result value SHALL consist of the COSE
121 structure indicated by Table 1 in its decoded form.
123 +-----------+------------------+
124 | Result ID | Result Structure |
125 +-----------+------------------+
126 | 97 | COSE_Mac |
127 | | |
128 | 17 | COSE_Mac0 |
129 | | |
130 | 98 | COSE_Sign |
131 | | |
132 | 18 | COSE_Sign1 |
133 +-----------+------------------+
135 Table 1: COSE Integrity Results
137 Each integrity result SHALL use the "detached" payload form with nil
138 payload value. The integrity result for COSE_Mac and COSE_Mac0
139 structures are computed by the procedure in Section 6.3 of [RFC8152].
140 The integrity result for COSE_Sign and COSE_Sign1 structures are
141 computed by the procedure in Section 4.4 of [RFC8152].
143 [NOTE: This differs from base BPSec in that the entire block and the
144 bundle primary is signed] The COSE "payload" used to generate a
145 signature or MAC result SHALL be the canonically serialized target
146 block, including the canonical block array structure. The COSE
147 "protected attributes from the application" used to generate a
148 signature or MAC result SHALL be either:
150 For a primary block target: An empty byte string.
152 For a canonical block target: The canonically serialized primary
153 block of the bundle.
155 3.1.1. Interoperability Algorithms
157 [NOTE: This is identical to the [I-D.ietf-dtn-bpsec-interop-sc]
158 minimum list.] The minimum set of integrity algorithms needed for
159 interoperability is listed here. The full set of algorithms
160 available is managed at [IANA-COSE].
162 +--------------+------+
163 | Name | Code |
164 +--------------+------+
165 | HMAC 256/256 | 5 |
166 +--------------+------+
168 Integrity Algorithms
170 3.2. COSE Confidentiality Context
172 The COSE Confidentiality Context has a Security Context ID of TBD-CC.
174 The confidentiality context SHALL allow only the Result IDs from
175 Table 2. Each confidentiality context result value SHALL consist of
176 the COSE structure indicated by Table 2 in its decoded form.
178 +-----------+------------------+
179 | Result ID | Result Structure |
180 +-----------+------------------+
181 | 96 | COSE_Encrypt |
182 | | |
183 | 16 | COSE_Encrypt0 |
184 +-----------+------------------+
186 Table 2: COSE Confidentiality Results
188 Only algorithms which support Authenticated Encryption with
189 Authenticated Data (AEAD) SHALL be usable in the first (content)
190 layer of a confidentiality result. Because COSE encryption with AEAD
191 appends the authentication tag with the ciphertext, the size of the
192 block-type-specific-data will grow after an encryption operation.
194 Each confidentiality result SHALL use the "detached" payload form
195 with nil payload value. The COSE plaintext and ciphertext correspond
196 exactly with the target block-type-specific-data. The
197 confidentiality result for COSE_Encrypt and COSE_Encrypt0 structures
198 are computed by the procedure in Section 5.3 of [RFC8152].
200 [NOTE: This differs from base BPSec in that AAD from the block and
201 the bundle primary is used] The COSE "plaintext" used to generate an
202 encrypt result SHALL be the block-type-specific-data of the target
203 block, the decoded byte string itself (not including the encoded CBOR
204 item header). The COSE "protected attributes from the application"
205 used to generate an encrypt result SHALL be the concatenation of the
206 following:
208 1. The canonically serialized primary block of the bundle.
210 2. The canonically serialized augmented target block, which has its
211 block-type-specific-data substituted with an empty byte string.
213 3.2.1. Interoperability Algorithms
215 [NOTE: This is identical to the [I-D.ietf-dtn-bpsec-interop-sc]
216 minimum list.] The minimum set of integrity algorithms needed for
217 interoperability is listed here. The full set of algorithms
218 available is managed at [IANA-COSE].
220 +---------+------+
221 | Name | Code |
222 +---------+------+
223 | A256GCM | 3 |
224 +---------+------+
226 Confidentiality Algorithms
228 4. Implementation Status
230 [NOTE to the RFC Editor: please remove this section before
231 publication, as well as the reference to [RFC7942].]
233 This section records the status of known implementations of the
234 protocol defined by this specification at the time of posting of this
235 Internet-Draft, and is based on a proposal described in [RFC7942].
236 The description of implementations in this section is intended to
237 assist the IETF in its decision processes in progressing drafts to
238 RFCs. Please note that the listing of any individual implementation
239 here does not imply endorsement by the IETF. Furthermore, no effort
240 has been spent to verify the information presented here that was
241 supplied by IETF contributors. This is not intended as, and must not
242 be construed to be, a catalog of available implementations or their
243 features. Readers are advised to note that other implementations can
244 exist.
246 5. Security Considerations
248 This section separates security considerations into threat categories
249 based on guidance of BCP 72 [RFC3552].
251 All of the security considerations of the underlying BPSec
252 [I-D.ietf-dtn-bpsec] apply to these new security contexts.
254 5.1. Threat: BPSec Block Replay
256 The bundle's primary block contains fields which should uniquely
257 identify a bundle: the Source Node ID, Creation Timestamp, and
258 fragment parameters (see Section 4.2.2 of [I-D.ietf-dtn-bpbis]).
259 Including the primary block in the AAD for integrity and
260 confidentiality binds the verification of the secured block to its
261 parent bundle and disallows replay of any block with its BIB or BCB.
263 This profile of COSE limits the encryption algorithms to only AEAD in
264 order to include the context of the encrypted data as AAD. If an
265 agent mistakenly allows the use of non-AEAD encryption when
266 decrypting and verifying a BCB, the possibility of block replay
267 attack is present.
269 5.2. Threat: Algorithm Vulnerabilities
271 Because this use of COSE leaves the specific algorithms chosen for
272 BIB and BCB use up to the applications securing bundle data, it is
273 important to use only COSE algorithms which are marked as recommended
274 in the IANA registry [IANA-COSE].
276 6. IANA Considerations
278 Registration procedures referred to in this section are defined in
279 [RFC8126].
281 6.1. BPSec Security Contexts
283 Within the "Bundle Protocol" registry [IANA-BUNDLE], the following
284 entry has been added to the "BPSec Security Context Identifiers" sub-
285 registry.
287 +--------+----------------------+---------------------+
288 | Value | Description | Reference |
289 +--------+----------------------+---------------------+
290 | TBD-CI | COSE Integrity | This specification. |
291 | | | |
292 | TBD-CC | COSE Confidentiality | This specification. |
293 +--------+----------------------+---------------------+
295 7. Acknowledgments
297 The interoperability minimum algorithms and parameters are based on
298 the draft [I-D.ietf-dtn-bpsec-interop-sc].
300 8. References
302 8.1. Normative References
304 [I-D.ietf-dtn-bpsec]
305 Birrane, E. and K. McKeever, "Bundle Protocol Security
306 Specification", draft-ietf-dtn-bpsec-22 (work in
307 progress), March 2020.
309 [IANA-BUNDLE]
310 IANA, "Bundle Protocol",
311 .
313 [IANA-COSE]
314 IANA, "CBOR Object Signing and Encryption (COSE)",
315 .
317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
318 Requirement Levels", BCP 14, RFC 2119,
319 DOI 10.17487/RFC2119, March 1997,
320 .
322 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
323 Writing an IANA Considerations Section in RFCs", BCP 26,
324 RFC 8126, DOI 10.17487/RFC8126, June 2017,
325 .
327 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
328 RFC 8152, DOI 10.17487/RFC8152, July 2017,
329 .
331 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
332 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
333 May 2017, .
335 8.2. Informative References
337 [I-D.ietf-dtn-bpbis]
338 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
339 Version 7", draft-ietf-dtn-bpbis-25 (work in progress),
340 May 2020.
342 [I-D.ietf-dtn-bpsec-interop-sc]
343 Birrane, E., "BPSec Interoperability Security Contexts",
344 draft-ietf-dtn-bpsec-interop-sc-01 (work in progress),
345 February 2020.
347 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
348 Text on Security Considerations", BCP 72, RFC 3552,
349 DOI 10.17487/RFC3552, July 2003,
350 .
352 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
353 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
354 October 2013, .
356 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
357 Code: The Implementation Status Section", BCP 205,
358 RFC 7942, DOI 10.17487/RFC7942, July 2016,
359 .
361 Appendix A. Examples
363 A.1. COSE_Mac0
365 This is an example of a MAC with implied recipient (and its key
366 material). The two provided figures are CBOR diagnostic notation
367 [RFC7049] of the target block being signed and the Abstract Security
368 Block (which will itself be enveloped within a BIB).
370 The 256-bit key used is
371 h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999dbae4ce45c'.
373 [
374 7, / BP version /
375 0, / flags /
376 0, / CRC type /
377 [1, '//dst/'], / destination /
378 [1, '//src/'], / source /
379 [1, '//src/'], / report-to /
380 [0, 40], / timestamp /
381 1000000 / lifetime /
382 ]
384 Figure 1: Primary block CBOR diagnostic
386 The primary block encodes to h'880700008201462f2f6473742f8201462f2f73
387 72632f8201462f2f7372632f820018281a000f4240'.
389 [
390 7, / type code - bundle age /
391 2, / block num /
392 0, / flags /
393 0, / CRC type /
394 h'19012c' / type-specific-data:
395 300 \ age \
396 /
397 ]
399 Figure 2: Target block CBOR diagnostic
401 The target data to be signed is concatenated from the primary encoded
402 and h'85070200004319012c'.
404 [
405 [2], / targets /
406 0, / security context TBD /
407 0, / flags /
408 [
409 [ / target block #2 /
410 [ / result /
411 17, / COSE_Mac0 tag /
412 [
413 h'a10105' / protected {
414 \ alg \ 1:5 \ HMAC 256//256 \
415 } / ,
416 {}, / unprotected /
417 null, / payload /
418 h'91d5f4025cf5fdaf4979ae288cc4aee85b556d4c8c4a87ba880e2dd0b9dd2219' / tag /
419 ]
420 ]
421 ]
422 ]
423 ]
425 Figure 3: Abstract Security Block CBOR diagnostic
427 A.2. COSE_Encrypt0
429 This is an example of an encryption with implied recipient (and its
430 key material). The provided figures are CBOR diagnostic notation
431 [RFC7049] of the target block being encrypted, the Abstract Security
432 Block (which will itself be enveloped within a BCB), and the
433 resulting target block.
435 The 256-bit key used is
436 h'13bf9cead057c0aca2c9e52471ca4b19ddfaf4c0784e3f3e8e3999dbae4ce45c'.
438 [
439 7, / BP version /
440 0, / flags /
441 0, / CRC type /
442 [1, '//dst/'], / destination /
443 [1, '//src/'], / source /
444 [1, '//src/'], / report-to /
445 [0, 40], / timestamp /
446 1000000 / lifetime /
447 ]
449 Figure 4: Primary block CBOR diagnostic
451 The primary block encodes to h'880700008201462f2f6473742f8201462f2f73
452 72632f8201462f2f7372632f820018281a000f4240'.
454 [
455 7, / type code - bundle age /
456 2, / block num /
457 0, / flags /
458 0, / CRC type /
459 h'19012c' / type-specific-data:
460 300 \ age \
461 /
462 ]
464 Figure 5: Initial Target block CBOR diagnostic
466 The target plaintext is h'19012c' with AAD concatenated from the
467 primary encoded and h'850702000040'. A random IV is generated for
468 this operation and is indicated in a standard way.
470 [
471 [2], / targets /
472 0, / security context TBD /
473 0, / flags /
474 [
475 [ / target block #2 /
476 [ / result /
477 16, / COSE_Encrypt0 tag /
478 [
479 h'a10103', / protected {
480 \ alg \ 1:3 \ A256GCM \
481 } /
482 { / unprotected /
483 / iv / 5: h'6f3093eba5d85143c3dc484a'
484 },
485 null / payload /
486 ]
487 ]
488 ]
489 ]
490 ]
492 Figure 6: Abstract Security Block CBOR diagnostic
494 [
495 7, / type code - bundle age /
496 2, / block num /
497 0, / flags /
498 0, / CRC type /
499 h'63bb16e3f7440706835f460dabc29e9dfc4284' / ciphertext /
500 ]
502 Figure 7: Encrypted Target block CBOR diagnostic
504 Author's Address
506 Brian Sipos
507 RKF Engineering Solutions, LLC
508 7500 Old Georgetown Road
509 Suite 1275
510 Bethesda, MD 20814-6198
511 United States of America
513 Email: BSipos@rkf-eng.com