--- 1/draft-ietf-dtn-bpsec-10.txt 2019-09-09 12:13:13.961602985 -0700 +++ 2/draft-ietf-dtn-bpsec-11.txt 2019-09-09 12:13:14.037604901 -0700 @@ -1,18 +1,18 @@ Delay-Tolerant Networking E. Birrane Internet-Draft K. McKeever Intended status: Standards Track JHU/APL -Expires: October 11, 2019 April 9, 2019 +Expires: March 12, 2020 September 9, 2019 Bundle Protocol Security Specification - draft-ietf-dtn-bpsec-10 + draft-ietf-dtn-bpsec-11 Abstract This document defines a security protocol providing end to end data integrity and confidentiality services for the Bundle Protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -20,21 +20,21 @@ 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 October 11, 2019. + This Internet-Draft will expire on March 12, 2020. Copyright Notice Copyright (c) 2019 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 @@ -46,65 +46,65 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Supported Security Services . . . . . . . . . . . . . . . 3 1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4 1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 7 - 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 7 + 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 8 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8 - 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 8 + 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 9 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 - 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10 + 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 - 3.5. Block Representation . . . . . . . . . . . . . . . . . . 11 + 3.5. Block Representation . . . . . . . . . . . . . . . . . . 12 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17 3.10. Parameter and Result Identification . . . . . . . . . . . 18 - 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 18 + 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 19 3.11.1. Example 1: Constructing a Bundle with Security . . . 19 3.11.2. Example 2: Adding More Security At A New Node . . . 20 - 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 21 + 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22 - 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22 - 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22 - 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23 - 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 24 - 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 24 - 7. Security Policy Considerations . . . . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 26 - 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 27 - 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 27 - 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 28 - 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 29 - 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 29 - 9. Security Context Considerations . . . . . . . . . . . . . . . 30 - 9.1. Identification and Configuration . . . . . . . . . . . . 30 + 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 23 + 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 23 + 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 24 + 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 25 + 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 25 + 7. Security Policy Considerations . . . . . . . . . . . . . . . 25 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 27 + 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 28 + 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 28 + 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29 + 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 30 + 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 30 + 9. Security Context Considerations . . . . . . . . . . . . . . . 31 + 9.1. Identification and Configuration . . . . . . . . . . . . 31 9.2. Authorship . . . . . . . . . . . . . . . . . . . . . . . 31 - 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 32 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 33 - - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 33 - 12.2. Informative References . . . . . . . . . . . . . . . . . 34 - Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34 + 11.2. Security Context Identifiers . . . . . . . . . . . . . . 34 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 + 12.2. Informative References . . . . . . . . . . . . . . . . . 35 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction This document defines security features for the Bundle Protocol (BP) [I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant Networks (DTNs) to provide end-to-end security services. The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as referring to "a networking architecture providing communications in and/or through highly stressed environments" where "BP may be viewed @@ -193,21 +193,24 @@ This specification addresses neither the fitness of externally- defined cryptographic methods nor the security of their implementation. Different networking conditions and operational considerations require varying strengths of security mechanism such that mandating a cipher suite in this specification may result in too much security for some networks and too little security in others. It is expected that separate documents will be standardized to define security contexts and cipher suites compatible with BPSec, to include those that should be used to assess interoperability and those fit - for operational use in various network scenarios. + for operational use in various network scenarios. A sample security + context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) to support + interoperability testing and serve as an exemplar for how security + contexts should be defined for this specification. This specification does not address the implementation of security policy and does not provide a security policy for the BPSec. Similar to cipher suites, security policies are based on the nature and capabilities of individual networks and network operational concepts. This specification does provide policy considerations when building a security policy. With the exception of the Bundle Protocol, this specification does not address how to combine the BPSec security blocks with other @@ -243,20 +246,26 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This section defines terminology either unique to the BPSec or otherwise necessary for understanding the concepts defined in this specification. + o Bundle Destination - the node which receives a bundle and delivers + the payload of the bundle to an application. Also, the Node ID of + the BPA receiving the bundle. The bundle destination acts as the + security destination for every security target in every security + block in every bundle it receives. + o Bundle Source - the node which originates a bundle. Also, the Node ID of the BPA originating the bundle. o Cipher Suite - a set of one or more algorithms providing integrity and confidentiality services. Cipher suites may define necessary parameters but do not provide values for those parameters. o Forwarder - any node that transmits a bundle in the DTN. Also, the Node ID of the Bundle Protocol Agent (BPA) that sent the bundle on its most recent hop. @@ -267,20 +276,23 @@ o Path - the ordered sequence of nodes through which a bundle passes on its way from Source to Destination. The path is not necessarily known in advance by the bundle or any BPAs in the DTN. o Security Block - a BPSec extension block in a bundle. o Security Context - the set of assumptions, algorithms, configurations and policies used to implement security services. + o Security Destination - a bundle node that processes one or more + security blocks in a bundle. Also, the Node ID of that node. + o Security Operation - the application of a security service to a security target, notated as OP(security service, security target). For example, OP(confidentiality, payload). Every security operation in a bundle MUST be unique, meaning that a security service can only be applied to a security target once in a bundle. A security operation is implemented by a security block. o Security Service - the security features supported by this specification: either integrity or confidentiality. @@ -472,36 +484,43 @@ block when all of the following conditions are true. o The security operations apply the same security service. For example, they are all integrity operations or all confidentiality operations. o The security context parameters and key information for the security operations are identical. o The security source for the security operations is the same. - Meaning the set of operations are being added/removed by the same - node. + Meaning the set of operations are being added by the same node. o No security operations have the same security target, as that would violate the need for security operations to be unique. o None of the security operations conflict with security operations already present in the bundle. When representing multiple security operations in a single security block, the information that is common across all operations is represented once in the security block, and the information which is different (e.g., the security targets) are represented individually. - When the security block is processed all security operations - represented by the security block MUST be applied/evaluated at that - time. + + It is RECOMMENDED that if a node processes any security operation in + a security block that it process all security operations in the + security block. This allows security sources to assert that the set + of security operations in a security block are expected to be + processed by the same security destination. However, the + determination of whether a node actually is a security destination or + not is a matter of the policy of the node itself. In cases where a + receiving node determines that it is the security destination of only + a subset of the security operations in a security block, the node may + choose to only process that subset of security operations. 3.4. Target Identification A security target is a block in the bundle to which a security service applies. This target must be uniquely and unambiguously identifiable when processing a security block. The definition of the extension block header from [I-D.ietf-dtn-bpbis] provides a "Block Number" field suitable for this purpose. Therefore, a security target in a security block MUST be represented as the Block Number of the target block. @@ -552,35 +572,31 @@ Security Context Id: This field identifies the security context used to implement the security service represented by this block and applied to each security target. This field SHALL be represented by a CBOR unsigned integer. Security Context Flags: This field identifies which optional fields are present in the security block. This field SHALL be represented as a CBOR - unsigned integer containing a bit field of 5 bits indicating - the presence or absence of other security block fields, as - follows. - - Bit 1 (the most-significant bit, 0x10): reserved. - - Bit 2 (0x08): reserved. - - Bit 3 (0x04): reserved. - - Bit 4 (0x02): Security Source Present Flag. + unsigned integer whose contents shall be interpreted as a bit + field. Each bit in this bit field indicates the presence (bit + set to 1) or absence (bit set to 0) of optional data in the + security block. The association of bits to security block data + is defined as follows. - Bit 5 (the least-significant bit, 0x01): Security Context + Bit 1 (the least-significant bit, 0x01): Security Context Parameters Present Flag. + Bit 2 (0x02): Security Source Present Flag. + In this field, a value of 1 indicates that the associated security block field MUST be included in the security block. A value of 0 indicates that the associated security block field MUST NOT be in the security block. Security Source (Optional): This field identifies the Endpoint that inserted the security block in the bundle. If the security source field is not present then the source MUST be inferred from other information, such as the bundle source, previous hop, or other @@ -729,22 +745,22 @@ reference the payload block, a non-security extension block, or a BIB. A BCB MUST NOT include another BCB as a security target. A BCB MUST NOT target the primary block. The Security Context Id MUST utilize a confidentiality cipher that provides authenticated encryption with associated data (AEAD). Additional information created by a cipher suite (such as additional authenticated data) can be placed either in a security result field or in the generated cipher-text. The determination - of where to place these data is a function of the cipher suite - used. + of where to place these data is a function of the cipher suite and + security context used. An EID-reference to the security source MAY be present. If this field is not present, then the security source of the block SHOULD be inferred according to security policy and MAY default to the bundle source. The security source MAY be specified as part of the key information described in Section 3.10. The BCB modifies the contents of its security target(s). When a BCB is applied, the security target body data are encrypted "in-place". Following encryption, the security target Block Type Specific Data @@ -781,24 +797,25 @@ o When adding a BCB to a bundle, if some (or all) of the security targets of the BCB also match all of the security targets of an existing BIB, then the existing BIB MUST also be encrypted. This can be accomplished by either adding a new BCB that targets the existing BIB, or by adding the BIB to the list of security targets for the BCB. Deciding which way to represent this situation is a matter of security policy. o When adding a BCB to a bundle, if some (or all) of the security targets of the BCB match some (but not all) of the security - targets of a BIB, then a new BIB MUST be created and all entries - relating to those BCB security targets MUST be moved from the - original BIB to the newly created BIB. The newly created BIB MUST - then be encrypted. This can be accomplished by either adding a + targets of a BIB then that BIB MUST be altered in the following + way. Any security results in the BIB associated with the BCB + security targets MUST be removed from the BIB and placed in a new + BIB. This newly created BIB MUST then be encrypted. The + encryption of the new BIB can be accomplished by either adding a new BCB that targets the new BIB, or by adding the new BIB to the list of security targets for the BCB. Deciding which way to represent this situation is a matter of security policy. o A BIB MUST NOT be added for a security target that is already the security target of a BCB. In this instance, the BCB is already providing authentication and integrity of the security target and the BIB would be redundant, insecure, and cause ambiguity in block processing order. @@ -825,36 +842,28 @@ NOTE: Since any cipher suite used with a BCB MUST be an AEAD cipher suite, it is inefficient and possibly insecure for a single security source to add both a BIB and a BCB for the same security target. In cases where a security source wishes to calculate both a plain-text integrity mechanism and encrypt a security target, a BCB with a cipher suite that generates such signatures as additional security results SHOULD be used instead. 3.10. Parameter and Result Identification - Security context parameters and results each represent multiple - distinct pieces of information in a security block. Each piece of - information is assigned an identifier and a CBOR encoding. - Identifiers MUST be unique for a given cipher suite but do not need - to be unique across all cipher suites. Therefore, parameter Ids and - result Ids are specified in the context of a cipher suite definition. - - Individual BPSec security context identifiers SHOULD use existing - registries of identifiers and CBOR encodings, such as those defined - in [RFC8152], whenever possible. Contexts SHOULD define their own - identifiers and CBOR encodings when necessary. + Each security context MUST define its own context parameters and + security results. Each defined parameter and result is represented + as the tuple of an identifier and a value. Identifiers are always + represented as a CBOR unsigned integer. The CBOR encoding of values + is as defined by the security context specification. - Parameters and results are represented using CBOR, and any - identification of a new parameter or result must include how the - value will be represented using the CBOR specification. Ids - themselves are always represented as a CBOR unsigned integer. + Identifiers MUST be unique for a given security context but do not + need to be unique amongst all security contexts. 3.11. BSP Block Examples This section provides two examples of BPSec blocks applied to a bundle. In the first example, a single node adds several security operations to a bundle. In the second example, a waypoint node received the bundle created in the first example and adds additional security operations. In both examples, the first column represents blocks within a bundle and the second column represents the Block Number for the block, using the terminology B1...Bn for the purpose @@ -997,48 +1007,54 @@ Fields from plain-text to cipher-text. o Reserved flags MUST NOT be included in any canonicalization as it is not known if those flags will change in transit. These canonicalization algorithms assume that Endpoint IDs do not change from the time at which a security source adds a security block to a bundle and the time at which a node processes that security block. - Cipher suites MAY define their own canonicalization algorithms and - require the use of those algorithms over the ones provided in this - specification. In the event of conflicting canonicalization - algorithms, cipher suite algorithms take precedence over this - specification. + Cipher suites and security contexts MAY define their own + canonicalization algorithms and require the use of those algorithms + over the ones provided in this specification. In the event of + conflicting canonicalization algorithms, those algorithms take + precedence over this specification. 5. Security Processing This section describes the security aspects of bundle processing. 5.1. Bundles Received from Other Nodes Security blocks must be processed in a specific order when received by a security-aware node. The processing order is as follows. o When BIBs and BCBs share a security target, BCBs MUST be evaluated first and BIBs second. 5.1.1. Receiving BCBs If a received bundle contains a BCB, the receiving node MUST - determine whether it has the responsibility of decrypting the BCB - security target and removing the BCB prior to delivering data to an - application at the node or forwarding the bundle. + determine whether it is the security destination for any of the + security operations in the BCB. If so, the node MUST process those + operations and remove any operation-specific information from the BCB + prior to delivering data to an application at the node or forwarding + the bundle. If processing a security operation fails, the target + SHALL be processed according to the security policy. A bundle status + report indicating the failure MAY be generated. When all security + operations for a BCB have been removed from the BCB, the BCB MUST be + removed from the bundle. If the receiving node is the destination of the bundle, the node MUST decrypt any BCBs remaining in the bundle. If the receiving node is - not the destination of the bundle, the node MUST decrypt the BCB if + not the destination of the bundle, the node MUST process the BCB if directed to do so as a matter of security policy. If the security policy of a security-aware node specifies that a bundle should have applied confidentiality to a specific security target and no such BCB is present in the bundle, then the node MUST process this security target in accordance with the security policy. This may involve removing the security target from the bundle. If the removed security target is the payload block, the bundle MUST be discarded. @@ -1049,68 +1065,70 @@ and all security blocks associated with that target MUST be discarded and processed no further. In both cases, requested status reports (see [I-D.ietf-dtn-bpbis]) MAY be generated to reflect bundle or block deletion. When a BCB is decrypted, the recovered plain-text MUST replace the cipher-text in the security target Block Type Specific Data Fields. If the Block Data Length field was modified at the time of encryption it MUST be updated to reflect the decrypted block length. - If a BCB contains multiple security targets, all security targets - MUST be processed when the BCB is processed. Errors and other - processing steps SHALL be made as if each security target had been - represented by an individual BCB with a single security target. + If a BCB contains multiple security operations, each operation + processed by the node MUST be be treated as if the security operation + has been represented by a single BCB with a single security + operation. 5.1.2. Receiving BIBs If a received bundle contains a BIB, the receiving node MUST - determine whether it has the final responsibility of verifying the - BIB security target and removing it prior to delivering data to an - application at the node or forwarding the bundle. If a BIB check - fails, the security target has failed to authenticate and the - security target SHALL be processed according to the security policy. - A bundle status report indicating the failure MAY be generated. - Otherwise, if the BIB verifies, the security target is ready to be - processed for delivery. + determine whether it is the security destination for any of the + security operations in the BIB. If so, the node MUST process those + operations and remove any operation-specific information from the BIB + prior to delivering data to an application at the node or forwarding + the bundle. If processing a security operation fails, the target + SHALL be processed according to the security policy. A bundle status + report indicating the failure MAY be generated. When all security + operations for a BIB have been removed from the BIB, the BIB MUST be + removed from the bundle. A BIB MUST NOT be processed if the security target of the BIB is also the security target of a BCB in the bundle. Given the order of operations mandated by this specification, when both a BIB and a BCB share a security target, it means that the security target must have been encrypted after it was integrity signed and, therefore, the BIB cannot be verified until the security target has been decrypted by processing the BCB. If the security policy of a security-aware node specifies that a bundle should have applied integrity to a specific security target and no such BIB is present in the bundle, then the node MUST process this security target in accordance with the security policy. This may involve removing the security target from the bundle. If the removed security target is the payload or primary block, the bundle MAY be discarded. This action can occur at any node that has the ability to verify an integrity signature, not just the bundle destination. - If a receiving node does not have the final responsibility of - verifying the BIB it MAY attempt to verify the BIB to prevent the - needless forwarding of corrupt data. If the check fails, the node - SHALL process the security target in accordance to local security - policy. It is RECOMMENDED that if a payload integrity check fails at - a waypoint that it is processed in the same way as if the check fails - at the destination. If the check passes, the node MUST NOT remove - the BIB prior to forwarding. + If a receiving node is not the security destination of a security + operation in a BIB it MAY attempt to verify the security operation + anyway to prevent forwarding corrupt data. If the verification + fails, the node SHALL process the security target in accordance to + local security policy. It is RECOMMENDED that if a payload integrity + check fails at a waypoint that it is processed in the same way as if + the check fails at the bundle destination. If the check passes, the + node MUST NOT remove the security operation from the BIB prior to + forwarding. - If a BIB contains multiple security targets, all security targets - MUST be processed if the BIB is processed by the Node. Errors and - other processing steps SHALL be made as if each security target had - been represented by an individual BIB with a single security target. + If a BIB contains multiple security operations, each operation + processed by the node MUST be be treated as if the security operation + has been represented by a single BIB with a single security + operation. 5.2. Bundle Fragmentation and Reassembly If it is necessary for a node to fragment a bundle payload, and security services have been applied to that bundle, the fragmentation rules described in [I-D.ietf-dtn-bpbis] MUST be followed. As defined there and summarized here for completeness, only the payload block can be fragmented; security blocks, like all extension blocks, can never be fragmented. @@ -1538,87 +1556,108 @@ and configuration associated with blocks SHOULD be included in any OSB definition. NOTE: The burden of showing compliance with processing rules is placed upon the standards defining new security blocks and the identification of such blocks shall not, alone, require maintenance of this specification. 11. IANA Considerations - A registry of security context identifiers will be required. + This specification includes fields requiring registries managed by + IANA. 11.1. Bundle Block Types This specification allocates two block types from the existing - "Bundle Block Types" registry defined in [RFC6255]. + "Bundle Block Types" registry defined in [I-D.ietf-dtn-bpbis]. Additional Entries for the Bundle Block-Type Codes Registry: +-------+-----------------------------+---------------+ | Value | Description | Reference | +-------+-----------------------------+---------------+ - | TBD | Block Integrity Block | This document | - | TBD | Block Confidentiality Block | This document | + | 2 | Block Integrity Block | This document | + | 3 | Block Confidentiality Block | This document | +-------+-----------------------------+---------------+ Table 2 +11.2. Security Context Identifiers + + BPSec has a Security Context Identifier field () for which IANA is + requested to create and maintain a new registry named "BPSec Security + Context Identifiers". Initial values for this registry are given + below. + + The registration policy for this registry is: Specification Required. + + The value range is: unsigned 16-bit integer. + + BPSec Security Context Identifier Registry + + +-------+--------------------+---------------------------------+ + | Value | Description | Reference | + +-------+--------------------+---------------------------------+ + | 0 | Reserved | This document | + | 1 | BIB-HMAC256-SHA256 | [I-D.ietf-dtn-bpsec-interop-sc] | + | 2 | BCB-AES-GCM-256 | [I-D.ietf-dtn-bpsec-interop-sc] | + +-------+--------------------+---------------------------------+ + + Table 3 + 12. References 12.1. Normative References [I-D.ietf-dtn-bpbis] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol - Version 7", draft-ietf-dtn-bpbis-11 (work in progress), - May 2018. + Version 7", draft-ietf-dtn-bpbis-14 (work in progress), + August 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . - [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol - IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May - 2011, . - [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . 12.2. Informative References [I-D.birrane-dtn-sbsp] Birrane, E., Pierce-Mayer, J., and D. Iannicca, "Streamlined Bundle Security Protocol Specification", draft-birrane-dtn-sbsp-01 (work in progress), October 2015. + [I-D.ietf-dtn-bpsec-interop-sc] + Birrane, E., "BPSec Interoperability Security Contexts", + draft-ietf-dtn-bpsec-interop-sc-00 (work in progress), + March 2019. + [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, . [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, DOI 10.17487/RFC6257, May 2011, . - [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", - RFC 8152, DOI 10.17487/RFC8152, July 2017, - . - Appendix A. Acknowledgements The following participants contributed technical material, use cases, and useful thoughts on the overall approach to this security specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy Alford and Angela Hennessy of the Laboratory for Telecommunications Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins University Applied Physics Laboratory. Authors' Addresses