Internet DRAFT - draft-birrane-dtn-scot
draft-birrane-dtn-scot
Delay-Tolerant Networking E. Birrane
Internet-Draft S. Heiner
Intended status: Standards Track JHU/APL
Expires: January 11, 2021 July 10, 2020
Security Context Template
draft-birrane-dtn-scot-00
Abstract
This document defines a standard template for security contexts
written for the Bundle Protocol Security Protocol (BPSec).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 11, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Birrane & Heiner Expires January 11, 2021 [Page 1]
Internet-Draft Security Context Template July 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification Scope . . . . . . . . . . . . . . . . . . . 3
1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Methods of Establishing Context . . . . . . . . . . . . . 4
2.1.1. Out-Of-Band Mode . . . . . . . . . . . . . . . . . . 4
2.1.2. In-Band Mode . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Hybrid Mode . . . . . . . . . . . . . . . . . . . . . 6
2.2. Security Policy Roles . . . . . . . . . . . . . . . . . . 7
2.3. Common Events and Actions . . . . . . . . . . . . . . . . 8
2.3.1. Bundle Protocol Reason Codes . . . . . . . . . . . . 8
2.3.2. Event Codes . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Processing Actions . . . . . . . . . . . . . . . . . 12
2.4. Security Policy Considerations . . . . . . . . . . . . . 14
2.5. Security Context Template . . . . . . . . . . . . . . . . 15
2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 16
2.5.2. Interfaces . . . . . . . . . . . . . . . . . . . . . 16
2.5.3. Definitions . . . . . . . . . . . . . . . . . . . . . 17
2.5.4. Canonicalization Algorithms . . . . . . . . . . . . . 17
2.5.5. Processing . . . . . . . . . . . . . . . . . . . . . 18
2.5.6. Policy . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.7. IANA Considerations . . . . . . . . . . . . . . . . . 18
3. Normative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
The Bundle Protocol (BP) may operate in environments that prevent
reliable synchronization of session information, to include
negotiated cryptographic material. To accommodate for this
possibility, BP bundles may use extension blocks to carry annotative
information. The Bundle Protocol Security Protocol (BPSec) defines
security-related extension blocks (security blocks) to carry
cryptographic material, to optionally include material that might
otherwise be expected resident at communication endpoints. To
accomplish these, BPSec security blocks specify a "security context"
comprising the material generated for, carried with, and/or otherwise
utilized by the block.
Where BPSec security blocks traverse networks for which a
synchronized security mechanism exists, a security context can be
defined which minimally identifies endpoint information. For
example, in networks that support TLS, a security context can be
defined to carry TLS record information after a successful TLS
handshake has been used to synchronize state at the endpoints of the
Birrane & Heiner Expires January 11, 2021 [Page 2]
Internet-Draft Security Context Template July 2020
exchange. Alternatively, where no such synchronizing security
mechanisms exist, a security context can be defined which carries
necessary configuration, cryptographic material, and policy.
The diversity of networks in which BP, and thus BPSec, may be
deployed implies a diversity of network contexts in which security
may be applied. For this reason, it is expected that multiple
security contexts will be defined for BPSec security blocks, such
that BPSec agents may select the most suitable context. This
document defines a template for the documentation of security
contexts. This template includes Bundle Protocol (BP) reason codes,
discrete events in the life-cycle of a security block, and policy
actions that may be taken by a bundle node when processing a security
block.
1.1. Specification Scope
This document defines the information that must be addressed in the
definition of any BPSec security context specification.
Specifically, this document details the following information.
o Data specification requirements.
o Definitions and handling requirements for standard BP reason
codes.
o Definitions and handling requirements for standard error codes.
o Guidance for specifying context-specific parameters and results.
The SCoT addresses only that information necessary for the proper
specification, interpretation, and processing of BPSec security
blocks. Any specific security protocol, cipher suite, or enumeration
set other than those defined by BP and BPSec are not considered part
of this document.
1.2. Related Documents
This document is best read and understood within the context of the
following other DTN documents:
The Concise Binary Object Representation (CBOR) format [RFC7049]
defines a data format that allows for small code size, fairly small
message size, and extensibility without version negotiation. The
block-specific-data associated with BPSec security blocks are encoded
in this data format.
Birrane & Heiner Expires January 11, 2021 [Page 3]
Internet-Draft Security Context Template July 2020
The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and
processing of bundles, defines the extension block format used to
represent BPSec security blocks, and defines the canonical block
structure used by this specification.
The Bundle Security Protocol [I-D.ietf-dtn-bpsec] defines the BP
extension blocks used to implement security services in a DTN. This
also outlines the need for security contexts customized to the
networks in which BP and BPSec are deployed.
1.3. Terminology
This section defines terminology unique to the Security Context
Template. Definitions of other terms specific to BP and BPSec, such
as "Security Acceptor", "Security Block", "Security Context",
Security Operation", "Security Service", "Security Source", and
"Security Target" are as defined in BPSec [I-D.ietf-dtn-bpsec].
2. System Overview
This section describes how a security context is used by BPSec to
normalize the diversity of environments encountered by the Bundle
Protocol.
2.1. Methods of Establishing Context
The definition of a security context is based in the concept that
different networks would provide annotative security information in
different ways as a function of the capabilities of the network
itself. This section discusses three general methods of generating
context information: out-of-band, in-band, and a hybrid approach.
For each of these methods the term "in-band" refers to information
carried within a bundle.
2.1.1. Out-Of-Band Mode
The Out-of-Band method of context establishment utilizes out-of-band
information only, requiring session information to be pre-shared.
The sending and receiving nodes must be configured using an out-of-
band method such as separate key management, one-time padding, or ID-
based encryption and use a pre-placed session key in order to
establish the context.
Birrane & Heiner Expires January 11, 2021 [Page 4]
Internet-Draft Security Context Template July 2020
+-------------+ +-------------+
| | (3) +------------+ (4) | |
| BPA | -----------> | bundle | ----------> | BPA |
| | +------------+ | |
+-------------+ +-------------+
| Convergence | | Convergence |
| Layer | | Layer |
+-------------+ +-------------+
^ ^
| |
| (2) | (5)
| |
v v
__________ __________
/ \ / \
\__________/ \__________/
| | (1) | |
| Database | <-----------------------------------------> | Database |
\__________/ \__________/
In-Band Mode
Step 1 shows the out-of-band configuration of both the sending and
receiving nodes. A session key is pre-placed in the databases
accessible by the nodes in step 1. Step 2 shows the sending node
retrieving this session key which is used in step 3 to add a security
block to the bundle which may transport a shared key between the
sending and receiving nodes. The bundle arrives at the receiving
node in step 4, and the pre-placed session key is retrieved in step
5. The session key can be used along with the shared key to
establish the context between the two nodes.
2.1.2. In-Band Mode
The In-Band method of context establishment utilizes in-band
information only. The key encryption key for both the sending and
receiving node must be pre-placed so that the node can fetch the
information from its in-band database. The session key and any
additional information necessary to establish the context is
transported by the bundle. The receiving node must use its pre-
placed key-encryption-key in order to recover the session key when
the bundle is received.
Birrane & Heiner Expires January 11, 2021 [Page 5]
Internet-Draft Security Context Template July 2020
+-------------+ +-------------+
| | (3) +------------+ (4) | |
| BPA | -----------> | Bundle | ----------> | BPA |
| | +------------+ | |
+-------------+ +-------------+
| Convergence | | Convergence |
| Layer | | Layer |
+-------------+ +-------------+
^ ^
| |
| (2) | (5)
| |
v v
__________ __________
/ \ / \
\__________/ \__________/
| | | |
| Database | (1) (1) | Database |
\__________/ \__________/
In-Band Mode
Step 1 indicates that the key encryption key has been pre-placed at
both the sending and receiving node. The key encryption key is
supplied to the sending node in step 2, which then uses this key in
step 3 to add a security block to the bundle. This security block
contains a session key and other necessary security context
parameters used to establish the context. The bundle is received in
step 4, and the key encryption key pre-placed at the receiving node
is fetched in step 5. The key encryption key is used to recover the
session key from the bundle, and the session key can be used to
retrieve the rest of the security results from the block.
2.1.3. Hybrid Mode
Using the Hybrid method of context establishment, both in-band and
out-of-band information is utilized. A session key is negotiated
out-of-band, while any additional information necessary to establish
the context is transported by the bundle.
Birrane & Heiner Expires January 11, 2021 [Page 6]
Internet-Draft Security Context Template July 2020
+-------------+ +-------------+
| | (3) +------------+ (4) | |
| BPA | -----------> | Bundle | ----------> | BPA |
| | +------------+ | |
+-------------+ +-------------+
| Convergence | | Convergence |
| Layer | <--------------------------------------->| Layer |
+-------------+ (1) +-------------+
^ ^
| |
| (2) | (2)
| |
V V
__________ __________
/ \ / \
\__________/ \__________/
| | | |
| Database | | Database |
\__________/ \__________/
Hybrid Mode
Step 1 shows session establishment, performed by the convergence
layer of two BP nodes using in-band information including a
negotiated session key. At step 2, the session data is stored at
both nodes in their respective databases. The sending node adds a
security block to the bundle containing the information necessary to
establish the context in the form of security context parameters in
step 3. Step 4 shows the augmented bundle arriving at the receiving
node. The receiving node can then use the session data in its
database (in-band information) and the session information
transmitted in the bundle as security context parameters (out-of-band
information).
2.2. Security Policy Roles
A security context may be interpreted differently based on the role
of the BPSec-aware node processing the security service. This
section defines the roles associated with a security operation.
Security Source
A security source node must add the security service to the
bundle as specified by some policy. The bundle will first be
inspected to ensure that the newly required security block has
not already been added to the bundle. If it is determined that
the required security block is not already represented in the
bundle, a new security block is added and the specified
Birrane & Heiner Expires January 11, 2021 [Page 7]
Internet-Draft Security Context Template July 2020
security context is used to apply the security service to each
security target.
Security Verifier
A security verifier node must verify (not process) a security
service in the bundle as specified by the receiver security
policy.
A security verifier will verify the integrity signature(s)
stored as security results of the BIB if the security service
described by the receiver security policy rule is integrity.
If policy identifies a BCB for which the node is a security
verifier, authenticity of the data belonging to the BCB's
security targets is verified. Some confidentiality security
contexts may not support this action, as the cipher suite(s)
that they utilize do not expose an authentication function.
Security Acceptor
A security acceptor node must process a security service in the
bundle as specified by policy. In order to process a security
service, each security target belonging to the security block
must have its integrity verified and/or its contents decrypted.
2.3. Common Events and Actions
This section describes the identification of common events and
actions associated with the processing of BPSec blocks at bundle
nodes. Since these items are not specific to a single security
context, they should be considered standard across all defined
security contexts for BPSec.
2.3.1. Bundle Protocol Reason Codes
This section describes a set of reason codes associated with the
processing of a bundle based on a security analysis performed by a
BPSec-aware BPA.
Bundle protocol agents (BPAs) must process blocks and bundles in
accordance with both BP policy and BPSec policy. The decision to
receive, forward, deliver, or delete a bundle may be communicated to
the report-to address of the bundle, in the form of a status report,
as a method of tracking the progress of the bundle through the
network. The status report for a bundle may be augmented with a
"reason code" explaining why the particular action was taken on the
bundle.
Missing Security Service
Birrane & Heiner Expires January 11, 2021 [Page 8]
Internet-Draft Security Context Template July 2020
This reason code indicates that a bundle was missing one or
more required security services. This reason code is used when
a bundle is received by a security verifier or security
acceptor and is missing a security service required by that
verifier or acceptor.
Unknown Security Service
This reason code indicates that a security service present in a
bundle cannot be understood by the security verifier or
security acceptor of that service. For example, if a security
service references a security context identifier, cipher suite
name, or other parameter that is not known by the verifier/
acceptor then the service cannot be processed and this reason
code may be sent. This reason should not be sent by a node
that is not configured as a verifier or acceptor of the
service. There is no requirement that all BPSec-aware nodes in
a network be able to understand all security services in all
bundles in the network.
Unexpected Security Service
This reason code indicates that a BPSec-aware node received a
bundle which contained more security services than expected.
This is typically used to indicate that a bundle contained a
security service which was not required by the BPSec-aware node
receiving the bundle. This reason code should not be seen as
an error condition as it is expected that BPSec-aware nodes
will see security services in a bundle for which they are
neither a verifier nor an acceptor. In certain networks, this
reason code may be useful in identifying misconfiguration in
the network.
Failed Security Service
This reason code indicates that a BPSec-aware node was unable
to process an existing, known security service in a bundle.
This may occur when a security-source is unable to add a
required service to a bundle. This may occur if a security
service fails to verify at a security verifier. This may occur
is a security service fails to be processed at a security
acceptor.
Conflicting Security Services
This reason code indicates that a bundle received by a BPSec-
aware node included a set of security services disallowed by
the BPSec protocol and that security processing was unable to
be proceed because of a BPSec protocol violation.
Birrane & Heiner Expires January 11, 2021 [Page 9]
Internet-Draft Security Context Template July 2020
2.3.2. Event Codes
A life-cycle of a security operation within BPSec is independent of
the security context used to populate the contents of that security
operation. However, security contexts must provide guidance on how a
BPSec-aware node should react to these events for security operations
using that context.
This section identifies the unique events in the life-cycle of a
security operation that may identify processing points within a
security context.
2.3.2.1. Security Source Events
At a security source, three events may be associated with the
security operation as its life-cycle is initiated.
source_for_sop
When a node is designated as a security source for a security
operation, there is a security policy rule that requires the
security operation to be present in the bundle. When the
sender security policy rule that applies to the bundle is
identified, the security operation is acknowledged as needed.
sop_added_at_source
A security operation is added when it is represented in the
bundle as a fully populated security block. In order for the
security operation to be considered as added, the security
block must be allocated for the bundle, represented in the
bundle, and populated. Population of a security block includes
information provided by the sender security policy rule and any
security results associated with the security operation. These
security results must be calculated and stored in either the
security block or the security target block's block-type-
specific data.
sop_misconfigured_at_source
When a security operation is transitioning from being needed to
added, it may end up misconfigured. A security operation may
be misconfigured if resource exhaustion occurs and there is not
appropriate space to store a required security block or other
components of the security block. A security operation will
also be considered to be misconfigured if any of the required
security results cannot be successfully calculated.
Birrane & Heiner Expires January 11, 2021 [Page 10]
Internet-Draft Security Context Template July 2020
2.3.2.2. Security Verifier Events
At a security verifier, five events may be associated with the
security operation.
verifier_for_sop
A node is designated as a security verifier when a receiver
security policy rule is identified which is applicable to the
current bundle and is associated with the security verifier
role. The security operation described by the rule is then
considered to be needed by the security verifier node.
sop_misconfigured_at_verifier
A security operation may be identified as misconfigured by the
security verifier node. A misconfigured security operation may
encounter a resource allocation issue and be unable to add an
additional, required security result. A misconfigured security
operation may also identify an incorrect security context or
parameter, causing a conflict the security policy rule.
sop_missing_at_verifier
A security operation may transition from needed to missing if
the required security block cannot be located in the bundle by
the security verifier node.
sop_corrupted_at_verifier
A corrupted security operation is identified as a security
block which is unsuccessfully processed by the security
verifier node. A corrupted security operation indicates that
the security target cannot be verified.
sop_verified
When a security operation is designated as processed, the
security target has been successfully verified.
2.3.2.3. Security Acceptor Events
At a security acceptor, five events may be associated with the
security operation.
acceptor_for_sop
A node is designated as a security acceptor when a receiver
security policy rule is identified that is both applicable to
the current bundle and associated with the security acceptor
role. The security operation described by the rule is then
considered to be needed by the security acceptor node.
sop_misconfigured_at_acceptor
Birrane & Heiner Expires January 11, 2021 [Page 11]
Internet-Draft Security Context Template July 2020
A security operation may be identified as misconfigured by the
security acceptor node. A misconfigured security operation
signals an incorrect security context or parameter, causing a
conflict the security policy rule.
sop_missing_at_acceptor
A security operation is missing if the required security block
cannot be located in the bundle by the security acceptor node.
sop_corrupted_at_acceptor
A corrupted security operation is identified as a security
block which is unsuccessfully processed by the security
acceptor node. A corrupted security operation indicates that
the security target cannot be verified and/or decrypted.
sop_processed
When a security operation is designated as processed, the
security target has been successfully verified and/or decrypted
and is removed from the bundle.
2.3.3. Processing Actions
This section defines a standard set of processing actions that can be
specified when defining the policy associated with a security
context. The benefit of enumerating these actions is to provide a
common set of terminology and design across multiple security
contexts with the purpose of making the development of multi-
security-context BPSec implementations as similar as possible.
In particular, a security context may wish to override how a BPSec
implementation treats the block processing control flags associated
with a security block and/or its target block using that context.
While the creator of a target block may set block processing flags it
may be insecure to process the block in accordance with those flags.
Similarly, if a target block has been modified since its was created,
it is possible that the target block's processing flags have also
been modified and should not necessarily be honored by a receiving
BPA.
A security context should specify the situations in which the
following actions should be taken by a BPSec implementation at a
BPSec-aware node in the network.
remove_sop
When the security operation is removed, it is no longer
required for that bundle. If the security operation is the
only operation represented by the security block, the block
must be removed from the bundle. Otherwise, the security
Birrane & Heiner Expires January 11, 2021 [Page 12]
Internet-Draft Security Context Template July 2020
target's block number is removed from the security block to
indicate that the particular operation no longer applies.
remove_sop_target
Remove security operation's security target and the security
operations associated with that target - The security
operation's security target is removed from the bundle, as are
any additional security operations associated with that target.
For example, if the target block of a confidentiality service
is removed, the integrity security operation for that target
would be removed as well.
remove_all_target_sops
Remove all security operations for the security target - This
option is used to remove all of the security operations
associated with the security target while retaining the
security target in the bundle.
do_not_forward
Selecting this option will end bundle transmission at the
current node, regardless of bundle destination.
request_storage
This option is paired with 'Do Not Forward Bundle' in order to
retain a copy of the bundle at the current node. Bundle
storage cannot be guaranteed, as node resources are unknown at
the time of bundle transmission, but selecting this option will
result in an effort to retain a copy of the bundle at the node.
report_reason_code(code)
Generate a status report describing the treatment of the bundle
and use the provided reason code as the reason.
override_target_bpcf(mask, new_values)
Override one or more block processing control flags of the the
target block and process the block in accordance with the
overridden flags. The overridden flags MUST NOT be written
back to the target block, and only used for processing the
block locally.
Manipulating individual flags to be forced to 0, forced to 1,
or kept as specified in the target block requires two inputs.
This can be accomplished by the operation:
local_flags = (block_flags & mask) | (~mask & values)
override_sop_bpcf(mask, new_values)
Birrane & Heiner Expires January 11, 2021 [Page 13]
Internet-Draft Security Context Template July 2020
Override one or more block processing control flags of the
security block associated with the sop and process the block in
accordance with the overridden flags. The overridden flags
MUST NOT be written back to the security block, and only used
for processing the block locally.
Manipulating individual flags to be forced to 0, forced to 1,
or kept as specified in the target block requires two inputs.
This can be accomplished by the operation:
local_flags = (block_flags & mask) | (~mask & values)
2.4. Security Policy Considerations
A security context details the environment in which cryptographic
materials are provided to, and retrieved from, the cipher suites used
for security services in the network. For this reason, the policy
associated with determining proper configuration information must be
addressed in the specifications defining new security contexts
because this information may differ amongst security contexts.
This section identifies several policy questions that should be
addressed in the specification of a security context. In the absence
of guidelines for a specific security context, this section defines
what should be considered default behavior for any security context.
Target Block Identification
Security contexts should define how a target block of a
security service should be identified. This identification is
used when determining whether to add a security block at a
security source, whether to check a security block at a
verifier, and whether a node should consider itself the
acceptor of the block.
DEFAULT BEHAVIOR: Unless otherwise specified, a target block
MUST be identified at a security source by the three-tuple of
{bundle source EID, bundle destination EID, and block type of
the target block}. A target block at a security verifier and a
security acceptor is identified by these three information
elements plus the security context identifier.
Security Parameter Local Overrides
Security contexts should define the circumstances in which a
local BPSec-aware node may override parameters in a security
block with locally-configured parameters.
DEFAULT BEHAVIOR: Unless otherwise specified, a locally-
provided security parameter MUST NOT override a security
Birrane & Heiner Expires January 11, 2021 [Page 14]
Internet-Draft Security Context Template July 2020
parameter present in a security block. A local parameter can
only be used in cases where the corresponding parameter is not
present in the security block itself.
Security Processing Actions
Security contexts should define the circumstances in which the
processing actions defined in Section 2.3.3 should be used and
with what inputs.
DEFAULT BEHAVIOR: Unless otherwise specified, the local, BPSec-
aware node MUST enforce policy actions as a function of some
local policy definition at the node itself. This may be
through the definition of generic actions for all security
contexts or it may be identified based on a specific security
context.
2.5. Security Context Template
This section defines a recommended outline for the definition of a
security context for BPSec. The purpose of such an outline is to
both ensure that no critical information is omitted when authoring
new security contexts and to reduce the cognitive load associated
with implementing new security contexts by having them confirm to a
standard representation.
A security context specification should include the following
elements.
1. Overview
2. Interfaces
3. Definitions
4. Canonicalization Algorithms
5. Processing
6. Policy
7. IANA Considerations
A single specification may define one or more security contexts, in
which case this information would be repeated for each security
context.
The remainder of this section provides information on the topics that
should be covered in each of these sections.
Birrane & Heiner Expires January 11, 2021 [Page 15]
Internet-Draft Security Context Template July 2020
2.5.1. Overview
This section should identify the rationale for creating a security
context, whether the context uses in-band, out-of-band, or hybrid
mechanisms for information exchange, and the unique situations in
which the context should be used.
2.5.2. Interfaces
Security context interfaces detail any special considerations or
assumptions made when designing the algorithms for creating or
otherwise processing the contents of security blocks.
2.5.2.1. Information Provided to the Cipher Suite
This section should identify how the security context interfaces with
the cipher suite (or cipher suites) used to process the security
service. This may be as simple as providing parameters from the
security block to a cipher suite implementation. This may also be a
more complex interface involving fusing parameter information carried
by the security block with local information to provide an interface
to the cipher suite.
A cipher suite may include parameters such as a key length, mode, or
number of rounds, which is part of the cipher suite definition.
These parameters are considered "locked" parameters and are not to be
confused with the "free" parameters that the user may define for each
security context. Where not already defined by the cipher suite
itself, the security context should clearly identify which parameters
should be considered "free" and which should be considered "locked".
In addition to listing cipher suites, this section should identify
information relating to all "free" cipher suite parameters. This may
include selected bit lengths, which parameters are provided by the
local node, which parameters must be present in the security block
itself, and how parameters should be protected when represented in a
security block.
2.5.2.2. Information Provided by the BPA
A security context specification should describe the information it
expects to be provided to it by the local BPA, separate from the
contents of the security block and target block from the bundle.
For example, a BPA may additionally provide local the security
context parameters.
Birrane & Heiner Expires January 11, 2021 [Page 16]
Internet-Draft Security Context Template July 2020
2.5.2.3. Information Provided to the BPA
A security context specification should describe the information that
it will provide back to the local BPA. Typically this is either the
output of a cipher suite to be added to a security block in a bundle,
or some signal for a process event associated with a verification or
processing action.
2.5.3. Definitions
This section defines custom parameters and results associated with
the security context and carried either within a security block or as
part of local node configuration.
Each security context parameters and result is defined as a key-value
pair, where the key is a CBOR-encoded integer and the value is
defined as the CBOR encoding of its data type. This section must
define any unique parameters and results used by the security
context, to include the following information.
o The integer identifier of the parameter or result item.
o Whether multiple instances of this item can be present in a
security block at one time, and whether at least one instance of
this item is required to be defined.
o Whether this item must be present only in the security block, or
whether it can also be included as part of the configuration of a
local node, and how to determine which version of the item to use
in the event that it is defined in both the security block and the
local node.
o The data type of the item and how that data type must be CBOR
encoded for representation in the security block.
2.5.4. Canonicalization Algorithms
Security context canonicalization algorithms take precedence over any
others defined. The exact data and its form when provided to the
canonicalization algorithm must be determined by the security
context.
Consistency and determinism of the block-type-specific data provided
as input to the security context is critical for security services to
function as expected.
Birrane & Heiner Expires January 11, 2021 [Page 17]
Internet-Draft Security Context Template July 2020
2.5.5. Processing
A security context specification should describe how the context
should be used to perform every processing action described in
Section 2.3.2.
2.5.6. Policy
A security context specification should describe how the context
should be configured from a policy perspective. This should include,
at a minimum, under which circumstances each policy action identified
in Section 2.3.3 should be taken.
2.5.7. IANA Considerations
Each security context MUST provide an entry in the IANA security
context identifier registry to uniquely identify the identifiers of
each security context.
3. Normative References
[I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
Version 7", draft-ietf-dtn-bpbis-25 (work in progress),
May 2020.
[I-D.ietf-dtn-bpsec]
Birrane, E. and K. McKeever, "Bundle Protocol Security
Specification", draft-ietf-dtn-bpsec-22 (work in
progress), March 2020.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
Authors' Addresses
Edward J. Birrane, III
The Johns Hopkins University Applied
Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
US
Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu
Birrane & Heiner Expires January 11, 2021 [Page 18]
Internet-Draft Security Context Template July 2020
Sarah Heiner
The Johns Hopkins University Applied
Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
US
Phone: +1 240 592 3704
Email: Sarah.Heiner@jhuapl.edu
Birrane & Heiner Expires January 11, 2021 [Page 19]
