idnits 2.17.1 draft-birrane-dtn-scot-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 587: '...e overridden flags MUST NOT be written...' RFC 2119 keyword, line 601: '... MUST NOT be written back to t...' RFC 2119 keyword, line 633: '... MUST be identified at a secur...' RFC 2119 keyword, line 645: '...curity parameter MUST NOT override a s...' RFC 2119 keyword, line 656: '... aware node MUST enforce policy a...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2020) is 1386 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) == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-25 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-22 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking E. Birrane 3 Internet-Draft S. Heiner 4 Intended status: Standards Track JHU/APL 5 Expires: January 11, 2021 July 10, 2020 7 Security Context Template 8 draft-birrane-dtn-scot-00 10 Abstract 12 This document defines a standard template for security contexts 13 written for the Bundle Protocol Security Protocol (BPSec). 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 11, 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Specification Scope . . . . . . . . . . . . . . . . . . . 3 51 1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 3 52 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Methods of Establishing Context . . . . . . . . . . . . . 4 55 2.1.1. Out-Of-Band Mode . . . . . . . . . . . . . . . . . . 4 56 2.1.2. In-Band Mode . . . . . . . . . . . . . . . . . . . . 5 57 2.1.3. Hybrid Mode . . . . . . . . . . . . . . . . . . . . . 6 58 2.2. Security Policy Roles . . . . . . . . . . . . . . . . . . 7 59 2.3. Common Events and Actions . . . . . . . . . . . . . . . . 8 60 2.3.1. Bundle Protocol Reason Codes . . . . . . . . . . . . 8 61 2.3.2. Event Codes . . . . . . . . . . . . . . . . . . . . . 10 62 2.3.3. Processing Actions . . . . . . . . . . . . . . . . . 12 63 2.4. Security Policy Considerations . . . . . . . . . . . . . 14 64 2.5. Security Context Template . . . . . . . . . . . . . . . . 15 65 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 16 66 2.5.2. Interfaces . . . . . . . . . . . . . . . . . . . . . 16 67 2.5.3. Definitions . . . . . . . . . . . . . . . . . . . . . 17 68 2.5.4. Canonicalization Algorithms . . . . . . . . . . . . . 17 69 2.5.5. Processing . . . . . . . . . . . . . . . . . . . . . 18 70 2.5.6. Policy . . . . . . . . . . . . . . . . . . . . . . . 18 71 2.5.7. IANA Considerations . . . . . . . . . . . . . . . . . 18 72 3. Normative References . . . . . . . . . . . . . . . . . . . . 18 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Introduction 77 The Bundle Protocol (BP) may operate in environments that prevent 78 reliable synchronization of session information, to include 79 negotiated cryptographic material. To accommodate for this 80 possibility, BP bundles may use extension blocks to carry annotative 81 information. The Bundle Protocol Security Protocol (BPSec) defines 82 security-related extension blocks (security blocks) to carry 83 cryptographic material, to optionally include material that might 84 otherwise be expected resident at communication endpoints. To 85 accomplish these, BPSec security blocks specify a "security context" 86 comprising the material generated for, carried with, and/or otherwise 87 utilized by the block. 89 Where BPSec security blocks traverse networks for which a 90 synchronized security mechanism exists, a security context can be 91 defined which minimally identifies endpoint information. For 92 example, in networks that support TLS, a security context can be 93 defined to carry TLS record information after a successful TLS 94 handshake has been used to synchronize state at the endpoints of the 95 exchange. Alternatively, where no such synchronizing security 96 mechanisms exist, a security context can be defined which carries 97 necessary configuration, cryptographic material, and policy. 99 The diversity of networks in which BP, and thus BPSec, may be 100 deployed implies a diversity of network contexts in which security 101 may be applied. For this reason, it is expected that multiple 102 security contexts will be defined for BPSec security blocks, such 103 that BPSec agents may select the most suitable context. This 104 document defines a template for the documentation of security 105 contexts. This template includes Bundle Protocol (BP) reason codes, 106 discrete events in the life-cycle of a security block, and policy 107 actions that may be taken by a bundle node when processing a security 108 block. 110 1.1. Specification Scope 112 This document defines the information that must be addressed in the 113 definition of any BPSec security context specification. 114 Specifically, this document details the following information. 116 o Data specification requirements. 118 o Definitions and handling requirements for standard BP reason 119 codes. 121 o Definitions and handling requirements for standard error codes. 123 o Guidance for specifying context-specific parameters and results. 125 The SCoT addresses only that information necessary for the proper 126 specification, interpretation, and processing of BPSec security 127 blocks. Any specific security protocol, cipher suite, or enumeration 128 set other than those defined by BP and BPSec are not considered part 129 of this document. 131 1.2. Related Documents 133 This document is best read and understood within the context of the 134 following other DTN documents: 136 The Concise Binary Object Representation (CBOR) format [RFC7049] 137 defines a data format that allows for small code size, fairly small 138 message size, and extensibility without version negotiation. The 139 block-specific-data associated with BPSec security blocks are encoded 140 in this data format. 142 The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and 143 processing of bundles, defines the extension block format used to 144 represent BPSec security blocks, and defines the canonical block 145 structure used by this specification. 147 The Bundle Security Protocol [I-D.ietf-dtn-bpsec] defines the BP 148 extension blocks used to implement security services in a DTN. This 149 also outlines the need for security contexts customized to the 150 networks in which BP and BPSec are deployed. 152 1.3. Terminology 154 This section defines terminology unique to the Security Context 155 Template. Definitions of other terms specific to BP and BPSec, such 156 as "Security Acceptor", "Security Block", "Security Context", 157 Security Operation", "Security Service", "Security Source", and 158 "Security Target" are as defined in BPSec [I-D.ietf-dtn-bpsec]. 160 2. System Overview 162 This section describes how a security context is used by BPSec to 163 normalize the diversity of environments encountered by the Bundle 164 Protocol. 166 2.1. Methods of Establishing Context 168 The definition of a security context is based in the concept that 169 different networks would provide annotative security information in 170 different ways as a function of the capabilities of the network 171 itself. This section discusses three general methods of generating 172 context information: out-of-band, in-band, and a hybrid approach. 174 For each of these methods the term "in-band" refers to information 175 carried within a bundle. 177 2.1.1. Out-Of-Band Mode 179 The Out-of-Band method of context establishment utilizes out-of-band 180 information only, requiring session information to be pre-shared. 181 The sending and receiving nodes must be configured using an out-of- 182 band method such as separate key management, one-time padding, or ID- 183 based encryption and use a pre-placed session key in order to 184 establish the context. 186 +-------------+ +-------------+ 187 | | (3) +------------+ (4) | | 188 | BPA | -----------> | bundle | ----------> | BPA | 189 | | +------------+ | | 190 +-------------+ +-------------+ 191 | Convergence | | Convergence | 192 | Layer | | Layer | 193 +-------------+ +-------------+ 194 ^ ^ 195 | | 196 | (2) | (5) 197 | | 198 v v 199 __________ __________ 200 / \ / \ 201 \__________/ \__________/ 202 | | (1) | | 203 | Database | <-----------------------------------------> | Database | 204 \__________/ \__________/ 206 In-Band Mode 208 Step 1 shows the out-of-band configuration of both the sending and 209 receiving nodes. A session key is pre-placed in the databases 210 accessible by the nodes in step 1. Step 2 shows the sending node 211 retrieving this session key which is used in step 3 to add a security 212 block to the bundle which may transport a shared key between the 213 sending and receiving nodes. The bundle arrives at the receiving 214 node in step 4, and the pre-placed session key is retrieved in step 215 5. The session key can be used along with the shared key to 216 establish the context between the two nodes. 218 2.1.2. In-Band Mode 220 The In-Band method of context establishment utilizes in-band 221 information only. The key encryption key for both the sending and 222 receiving node must be pre-placed so that the node can fetch the 223 information from its in-band database. The session key and any 224 additional information necessary to establish the context is 225 transported by the bundle. The receiving node must use its pre- 226 placed key-encryption-key in order to recover the session key when 227 the bundle is received. 229 +-------------+ +-------------+ 230 | | (3) +------------+ (4) | | 231 | BPA | -----------> | Bundle | ----------> | BPA | 232 | | +------------+ | | 233 +-------------+ +-------------+ 234 | Convergence | | Convergence | 235 | Layer | | Layer | 236 +-------------+ +-------------+ 237 ^ ^ 238 | | 239 | (2) | (5) 240 | | 241 v v 242 __________ __________ 243 / \ / \ 244 \__________/ \__________/ 245 | | | | 246 | Database | (1) (1) | Database | 247 \__________/ \__________/ 249 In-Band Mode 251 Step 1 indicates that the key encryption key has been pre-placed at 252 both the sending and receiving node. The key encryption key is 253 supplied to the sending node in step 2, which then uses this key in 254 step 3 to add a security block to the bundle. This security block 255 contains a session key and other necessary security context 256 parameters used to establish the context. The bundle is received in 257 step 4, and the key encryption key pre-placed at the receiving node 258 is fetched in step 5. The key encryption key is used to recover the 259 session key from the bundle, and the session key can be used to 260 retrieve the rest of the security results from the block. 262 2.1.3. Hybrid Mode 264 Using the Hybrid method of context establishment, both in-band and 265 out-of-band information is utilized. A session key is negotiated 266 out-of-band, while any additional information necessary to establish 267 the context is transported by the bundle. 269 +-------------+ +-------------+ 270 | | (3) +------------+ (4) | | 271 | BPA | -----------> | Bundle | ----------> | BPA | 272 | | +------------+ | | 273 +-------------+ +-------------+ 274 | Convergence | | Convergence | 275 | Layer | <--------------------------------------->| Layer | 276 +-------------+ (1) +-------------+ 277 ^ ^ 278 | | 279 | (2) | (2) 280 | | 281 V V 282 __________ __________ 283 / \ / \ 284 \__________/ \__________/ 285 | | | | 286 | Database | | Database | 287 \__________/ \__________/ 289 Hybrid Mode 291 Step 1 shows session establishment, performed by the convergence 292 layer of two BP nodes using in-band information including a 293 negotiated session key. At step 2, the session data is stored at 294 both nodes in their respective databases. The sending node adds a 295 security block to the bundle containing the information necessary to 296 establish the context in the form of security context parameters in 297 step 3. Step 4 shows the augmented bundle arriving at the receiving 298 node. The receiving node can then use the session data in its 299 database (in-band information) and the session information 300 transmitted in the bundle as security context parameters (out-of-band 301 information). 303 2.2. Security Policy Roles 305 A security context may be interpreted differently based on the role 306 of the BPSec-aware node processing the security service. This 307 section defines the roles associated with a security operation. 309 Security Source 310 A security source node must add the security service to the 311 bundle as specified by some policy. The bundle will first be 312 inspected to ensure that the newly required security block has 313 not already been added to the bundle. If it is determined that 314 the required security block is not already represented in the 315 bundle, a new security block is added and the specified 316 security context is used to apply the security service to each 317 security target. 319 Security Verifier 320 A security verifier node must verify (not process) a security 321 service in the bundle as specified by the receiver security 322 policy. 324 A security verifier will verify the integrity signature(s) 325 stored as security results of the BIB if the security service 326 described by the receiver security policy rule is integrity. 328 If policy identifies a BCB for which the node is a security 329 verifier, authenticity of the data belonging to the BCB's 330 security targets is verified. Some confidentiality security 331 contexts may not support this action, as the cipher suite(s) 332 that they utilize do not expose an authentication function. 334 Security Acceptor 335 A security acceptor node must process a security service in the 336 bundle as specified by policy. In order to process a security 337 service, each security target belonging to the security block 338 must have its integrity verified and/or its contents decrypted. 340 2.3. Common Events and Actions 342 This section describes the identification of common events and 343 actions associated with the processing of BPSec blocks at bundle 344 nodes. Since these items are not specific to a single security 345 context, they should be considered standard across all defined 346 security contexts for BPSec. 348 2.3.1. Bundle Protocol Reason Codes 350 This section describes a set of reason codes associated with the 351 processing of a bundle based on a security analysis performed by a 352 BPSec-aware BPA. 354 Bundle protocol agents (BPAs) must process blocks and bundles in 355 accordance with both BP policy and BPSec policy. The decision to 356 receive, forward, deliver, or delete a bundle may be communicated to 357 the report-to address of the bundle, in the form of a status report, 358 as a method of tracking the progress of the bundle through the 359 network. The status report for a bundle may be augmented with a 360 "reason code" explaining why the particular action was taken on the 361 bundle. 363 Missing Security Service 364 This reason code indicates that a bundle was missing one or 365 more required security services. This reason code is used when 366 a bundle is received by a security verifier or security 367 acceptor and is missing a security service required by that 368 verifier or acceptor. 370 Unknown Security Service 371 This reason code indicates that a security service present in a 372 bundle cannot be understood by the security verifier or 373 security acceptor of that service. For example, if a security 374 service references a security context identifier, cipher suite 375 name, or other parameter that is not known by the verifier/ 376 acceptor then the service cannot be processed and this reason 377 code may be sent. This reason should not be sent by a node 378 that is not configured as a verifier or acceptor of the 379 service. There is no requirement that all BPSec-aware nodes in 380 a network be able to understand all security services in all 381 bundles in the network. 383 Unexpected Security Service 384 This reason code indicates that a BPSec-aware node received a 385 bundle which contained more security services than expected. 386 This is typically used to indicate that a bundle contained a 387 security service which was not required by the BPSec-aware node 388 receiving the bundle. This reason code should not be seen as 389 an error condition as it is expected that BPSec-aware nodes 390 will see security services in a bundle for which they are 391 neither a verifier nor an acceptor. In certain networks, this 392 reason code may be useful in identifying misconfiguration in 393 the network. 395 Failed Security Service 396 This reason code indicates that a BPSec-aware node was unable 397 to process an existing, known security service in a bundle. 398 This may occur when a security-source is unable to add a 399 required service to a bundle. This may occur if a security 400 service fails to verify at a security verifier. This may occur 401 is a security service fails to be processed at a security 402 acceptor. 404 Conflicting Security Services 405 This reason code indicates that a bundle received by a BPSec- 406 aware node included a set of security services disallowed by 407 the BPSec protocol and that security processing was unable to 408 be proceed because of a BPSec protocol violation. 410 2.3.2. Event Codes 412 A life-cycle of a security operation within BPSec is independent of 413 the security context used to populate the contents of that security 414 operation. However, security contexts must provide guidance on how a 415 BPSec-aware node should react to these events for security operations 416 using that context. 418 This section identifies the unique events in the life-cycle of a 419 security operation that may identify processing points within a 420 security context. 422 2.3.2.1. Security Source Events 424 At a security source, three events may be associated with the 425 security operation as its life-cycle is initiated. 427 source_for_sop 428 When a node is designated as a security source for a security 429 operation, there is a security policy rule that requires the 430 security operation to be present in the bundle. When the 431 sender security policy rule that applies to the bundle is 432 identified, the security operation is acknowledged as needed. 434 sop_added_at_source 435 A security operation is added when it is represented in the 436 bundle as a fully populated security block. In order for the 437 security operation to be considered as added, the security 438 block must be allocated for the bundle, represented in the 439 bundle, and populated. Population of a security block includes 440 information provided by the sender security policy rule and any 441 security results associated with the security operation. These 442 security results must be calculated and stored in either the 443 security block or the security target block's block-type- 444 specific data. 446 sop_misconfigured_at_source 447 When a security operation is transitioning from being needed to 448 added, it may end up misconfigured. A security operation may 449 be misconfigured if resource exhaustion occurs and there is not 450 appropriate space to store a required security block or other 451 components of the security block. A security operation will 452 also be considered to be misconfigured if any of the required 453 security results cannot be successfully calculated. 455 2.3.2.2. Security Verifier Events 457 At a security verifier, five events may be associated with the 458 security operation. 460 verifier_for_sop 461 A node is designated as a security verifier when a receiver 462 security policy rule is identified which is applicable to the 463 current bundle and is associated with the security verifier 464 role. The security operation described by the rule is then 465 considered to be needed by the security verifier node. 467 sop_misconfigured_at_verifier 468 A security operation may be identified as misconfigured by the 469 security verifier node. A misconfigured security operation may 470 encounter a resource allocation issue and be unable to add an 471 additional, required security result. A misconfigured security 472 operation may also identify an incorrect security context or 473 parameter, causing a conflict the security policy rule. 475 sop_missing_at_verifier 476 A security operation may transition from needed to missing if 477 the required security block cannot be located in the bundle by 478 the security verifier node. 480 sop_corrupted_at_verifier 481 A corrupted security operation is identified as a security 482 block which is unsuccessfully processed by the security 483 verifier node. A corrupted security operation indicates that 484 the security target cannot be verified. 486 sop_verified 487 When a security operation is designated as processed, the 488 security target has been successfully verified. 490 2.3.2.3. Security Acceptor Events 492 At a security acceptor, five events may be associated with the 493 security operation. 495 acceptor_for_sop 496 A node is designated as a security acceptor when a receiver 497 security policy rule is identified that is both applicable to 498 the current bundle and associated with the security acceptor 499 role. The security operation described by the rule is then 500 considered to be needed by the security acceptor node. 502 sop_misconfigured_at_acceptor 503 A security operation may be identified as misconfigured by the 504 security acceptor node. A misconfigured security operation 505 signals an incorrect security context or parameter, causing a 506 conflict the security policy rule. 508 sop_missing_at_acceptor 509 A security operation is missing if the required security block 510 cannot be located in the bundle by the security acceptor node. 512 sop_corrupted_at_acceptor 513 A corrupted security operation is identified as a security 514 block which is unsuccessfully processed by the security 515 acceptor node. A corrupted security operation indicates that 516 the security target cannot be verified and/or decrypted. 518 sop_processed 519 When a security operation is designated as processed, the 520 security target has been successfully verified and/or decrypted 521 and is removed from the bundle. 523 2.3.3. Processing Actions 525 This section defines a standard set of processing actions that can be 526 specified when defining the policy associated with a security 527 context. The benefit of enumerating these actions is to provide a 528 common set of terminology and design across multiple security 529 contexts with the purpose of making the development of multi- 530 security-context BPSec implementations as similar as possible. 532 In particular, a security context may wish to override how a BPSec 533 implementation treats the block processing control flags associated 534 with a security block and/or its target block using that context. 535 While the creator of a target block may set block processing flags it 536 may be insecure to process the block in accordance with those flags. 537 Similarly, if a target block has been modified since its was created, 538 it is possible that the target block's processing flags have also 539 been modified and should not necessarily be honored by a receiving 540 BPA. 542 A security context should specify the situations in which the 543 following actions should be taken by a BPSec implementation at a 544 BPSec-aware node in the network. 546 remove_sop 547 When the security operation is removed, it is no longer 548 required for that bundle. If the security operation is the 549 only operation represented by the security block, the block 550 must be removed from the bundle. Otherwise, the security 551 target's block number is removed from the security block to 552 indicate that the particular operation no longer applies. 554 remove_sop_target 555 Remove security operation's security target and the security 556 operations associated with that target - The security 557 operation's security target is removed from the bundle, as are 558 any additional security operations associated with that target. 559 For example, if the target block of a confidentiality service 560 is removed, the integrity security operation for that target 561 would be removed as well. 563 remove_all_target_sops 564 Remove all security operations for the security target - This 565 option is used to remove all of the security operations 566 associated with the security target while retaining the 567 security target in the bundle. 569 do_not_forward 570 Selecting this option will end bundle transmission at the 571 current node, regardless of bundle destination. 573 request_storage 574 This option is paired with 'Do Not Forward Bundle' in order to 575 retain a copy of the bundle at the current node. Bundle 576 storage cannot be guaranteed, as node resources are unknown at 577 the time of bundle transmission, but selecting this option will 578 result in an effort to retain a copy of the bundle at the node. 580 report_reason_code(code) 581 Generate a status report describing the treatment of the bundle 582 and use the provided reason code as the reason. 584 override_target_bpcf(mask, new_values) 585 Override one or more block processing control flags of the the 586 target block and process the block in accordance with the 587 overridden flags. The overridden flags MUST NOT be written 588 back to the target block, and only used for processing the 589 block locally. 591 Manipulating individual flags to be forced to 0, forced to 1, 592 or kept as specified in the target block requires two inputs. 593 This can be accomplished by the operation: 595 local_flags = (block_flags & mask) | (~mask & values) 597 override_sop_bpcf(mask, new_values) 598 Override one or more block processing control flags of the 599 security block associated with the sop and process the block in 600 accordance with the overridden flags. The overridden flags 601 MUST NOT be written back to the security block, and only used 602 for processing the block locally. 604 Manipulating individual flags to be forced to 0, forced to 1, 605 or kept as specified in the target block requires two inputs. 606 This can be accomplished by the operation: 608 local_flags = (block_flags & mask) | (~mask & values) 610 2.4. Security Policy Considerations 612 A security context details the environment in which cryptographic 613 materials are provided to, and retrieved from, the cipher suites used 614 for security services in the network. For this reason, the policy 615 associated with determining proper configuration information must be 616 addressed in the specifications defining new security contexts 617 because this information may differ amongst security contexts. 619 This section identifies several policy questions that should be 620 addressed in the specification of a security context. In the absence 621 of guidelines for a specific security context, this section defines 622 what should be considered default behavior for any security context. 624 Target Block Identification 625 Security contexts should define how a target block of a 626 security service should be identified. This identification is 627 used when determining whether to add a security block at a 628 security source, whether to check a security block at a 629 verifier, and whether a node should consider itself the 630 acceptor of the block. 632 DEFAULT BEHAVIOR: Unless otherwise specified, a target block 633 MUST be identified at a security source by the three-tuple of 634 {bundle source EID, bundle destination EID, and block type of 635 the target block}. A target block at a security verifier and a 636 security acceptor is identified by these three information 637 elements plus the security context identifier. 639 Security Parameter Local Overrides 640 Security contexts should define the circumstances in which a 641 local BPSec-aware node may override parameters in a security 642 block with locally-configured parameters. 644 DEFAULT BEHAVIOR: Unless otherwise specified, a locally- 645 provided security parameter MUST NOT override a security 646 parameter present in a security block. A local parameter can 647 only be used in cases where the corresponding parameter is not 648 present in the security block itself. 650 Security Processing Actions 651 Security contexts should define the circumstances in which the 652 processing actions defined in Section 2.3.3 should be used and 653 with what inputs. 655 DEFAULT BEHAVIOR: Unless otherwise specified, the local, BPSec- 656 aware node MUST enforce policy actions as a function of some 657 local policy definition at the node itself. This may be 658 through the definition of generic actions for all security 659 contexts or it may be identified based on a specific security 660 context. 662 2.5. Security Context Template 664 This section defines a recommended outline for the definition of a 665 security context for BPSec. The purpose of such an outline is to 666 both ensure that no critical information is omitted when authoring 667 new security contexts and to reduce the cognitive load associated 668 with implementing new security contexts by having them confirm to a 669 standard representation. 671 A security context specification should include the following 672 elements. 674 1. Overview 676 2. Interfaces 678 3. Definitions 680 4. Canonicalization Algorithms 682 5. Processing 684 6. Policy 686 7. IANA Considerations 688 A single specification may define one or more security contexts, in 689 which case this information would be repeated for each security 690 context. 692 The remainder of this section provides information on the topics that 693 should be covered in each of these sections. 695 2.5.1. Overview 697 This section should identify the rationale for creating a security 698 context, whether the context uses in-band, out-of-band, or hybrid 699 mechanisms for information exchange, and the unique situations in 700 which the context should be used. 702 2.5.2. Interfaces 704 Security context interfaces detail any special considerations or 705 assumptions made when designing the algorithms for creating or 706 otherwise processing the contents of security blocks. 708 2.5.2.1. Information Provided to the Cipher Suite 710 This section should identify how the security context interfaces with 711 the cipher suite (or cipher suites) used to process the security 712 service. This may be as simple as providing parameters from the 713 security block to a cipher suite implementation. This may also be a 714 more complex interface involving fusing parameter information carried 715 by the security block with local information to provide an interface 716 to the cipher suite. 718 A cipher suite may include parameters such as a key length, mode, or 719 number of rounds, which is part of the cipher suite definition. 720 These parameters are considered "locked" parameters and are not to be 721 confused with the "free" parameters that the user may define for each 722 security context. Where not already defined by the cipher suite 723 itself, the security context should clearly identify which parameters 724 should be considered "free" and which should be considered "locked". 726 In addition to listing cipher suites, this section should identify 727 information relating to all "free" cipher suite parameters. This may 728 include selected bit lengths, which parameters are provided by the 729 local node, which parameters must be present in the security block 730 itself, and how parameters should be protected when represented in a 731 security block. 733 2.5.2.2. Information Provided by the BPA 735 A security context specification should describe the information it 736 expects to be provided to it by the local BPA, separate from the 737 contents of the security block and target block from the bundle. 739 For example, a BPA may additionally provide local the security 740 context parameters. 742 2.5.2.3. Information Provided to the BPA 744 A security context specification should describe the information that 745 it will provide back to the local BPA. Typically this is either the 746 output of a cipher suite to be added to a security block in a bundle, 747 or some signal for a process event associated with a verification or 748 processing action. 750 2.5.3. Definitions 752 This section defines custom parameters and results associated with 753 the security context and carried either within a security block or as 754 part of local node configuration. 756 Each security context parameters and result is defined as a key-value 757 pair, where the key is a CBOR-encoded integer and the value is 758 defined as the CBOR encoding of its data type. This section must 759 define any unique parameters and results used by the security 760 context, to include the following information. 762 o The integer identifier of the parameter or result item. 764 o Whether multiple instances of this item can be present in a 765 security block at one time, and whether at least one instance of 766 this item is required to be defined. 768 o Whether this item must be present only in the security block, or 769 whether it can also be included as part of the configuration of a 770 local node, and how to determine which version of the item to use 771 in the event that it is defined in both the security block and the 772 local node. 774 o The data type of the item and how that data type must be CBOR 775 encoded for representation in the security block. 777 2.5.4. Canonicalization Algorithms 779 Security context canonicalization algorithms take precedence over any 780 others defined. The exact data and its form when provided to the 781 canonicalization algorithm must be determined by the security 782 context. 784 Consistency and determinism of the block-type-specific data provided 785 as input to the security context is critical for security services to 786 function as expected. 788 2.5.5. Processing 790 A security context specification should describe how the context 791 should be used to perform every processing action described in 792 Section 2.3.2. 794 2.5.6. Policy 796 A security context specification should describe how the context 797 should be configured from a policy perspective. This should include, 798 at a minimum, under which circumstances each policy action identified 799 in Section 2.3.3 should be taken. 801 2.5.7. IANA Considerations 803 Each security context MUST provide an entry in the IANA security 804 context identifier registry to uniquely identify the identifiers of 805 each security context. 807 3. Normative References 809 [I-D.ietf-dtn-bpbis] 810 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 811 Version 7", draft-ietf-dtn-bpbis-25 (work in progress), 812 May 2020. 814 [I-D.ietf-dtn-bpsec] 815 Birrane, E. and K. McKeever, "Bundle Protocol Security 816 Specification", draft-ietf-dtn-bpsec-22 (work in 817 progress), March 2020. 819 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 820 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 821 October 2013, . 823 Authors' Addresses 825 Edward J. Birrane, III 826 The Johns Hopkins University Applied 827 Physics Laboratory 828 11100 Johns Hopkins Rd. 829 Laurel, MD 20723 830 US 832 Phone: +1 443 778 7423 833 Email: Edward.Birrane@jhuapl.edu 834 Sarah Heiner 835 The Johns Hopkins University Applied 836 Physics Laboratory 837 11100 Johns Hopkins Rd. 838 Laurel, MD 20723 839 US 841 Phone: +1 240 592 3704 842 Email: Sarah.Heiner@jhuapl.edu