| 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
This document defines a standard template for security contexts written for the Bundle Protocol Security Protocol (BPSec).
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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Bundle Protocol (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 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.
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.
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.
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.
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.
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].
This section describes how a security context is used by BPSec to normalize the diversity of environments encountered by the Bundle Protocol.
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.
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.
+-------------+ +-------------+
| | (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.
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.
+-------------+ +-------------+
| | (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.
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.
+-------------+ +-------------+
| | (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).
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.
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.
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.
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.
At a security source, three events may be associated with the security operation as its life-cycle is initiated.
At a security verifier, five events may be associated with the security operation.
At a security acceptor, five events may be associated with the security operation.
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.
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.
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.
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.
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.
Security context interfaces detail any special considerations or assumptions made when designing the algorithms for creating or otherwise processing the contents of security blocks.
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.
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.
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.
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.
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.
A security context specification should describe how the context should be used to perform every processing action described in Section 2.3.2.
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.
Each security context MUST provide an entry in the IANA security context identifier registry to uniquely identify the identifiers of each security context.
| [I-D.ietf-dtn-bpbis] | Burleigh, S., Fall, K. and E. Birrane, "Bundle Protocol Version 7", Internet-Draft draft-ietf-dtn-bpbis-25, May 2020. |
| [I-D.ietf-dtn-bpsec] | Birrane, E. and K. McKeever, "Bundle Protocol Security Specification", Internet-Draft draft-ietf-dtn-bpsec-22, March 2020. |
| [RFC7049] | Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013. |