draft-ietf-dtn-bpsec-04.txt   draft-ietf-dtn-bpsec-05.txt 
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft K. McKeever Internet-Draft K. McKeever
Intended status: Standards Track JHU/APL Intended status: Standards Track JHU/APL
Expires: September 13, 2017 March 12, 2017 Expires: January 2, 2018 July 1, 2017
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-04 draft-ietf-dtn-bpsec-05
Abstract Abstract
This document defines a security protocol providing end to end data This document defines a security protocol providing end to end data
integrity and confidentiality services for the Bundle Protocol. integrity and confidentiality services for the Bundle Protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2017. This Internet-Draft will expire on January 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Supported Security Services . . . . . . . . . . . . . . . 3
1.2. Supported Security Services . . . . . . . . . . . . . . . 3 1.2. Specification Scope . . . . . . . . . . . . . . . . . . . 4
1.3. Specification Scope . . . . . . . . . . . . . . . . . . . 4 1.3. Related Documents . . . . . . . . . . . . . . . . . . . . 5
1.4. Related Documents . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 6
2. Key Properties . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 6 2.1. Block-Level Granularity . . . . . . . . . . . . . . . . . 6
2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 7 2.2. Multiple Security Sources . . . . . . . . . . . . . . . . 7
2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 7 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 7
2.4. User-Selected Cipher Suites . . . . . . . . . . . . . . . 8 2.4. User-Selected Cipher Suites . . . . . . . . . . . . . . . 8
2.5. Deterministic Processing . . . . . . . . . . . . . . . . 8 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 8
3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 8
3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 9
3.4. Target Identification . . . . . . . . . . . . . . . . . . 10 3.4. Target Identification . . . . . . . . . . . . . . . . . . 10
3.5. Block Representation . . . . . . . . . . . . . . . . . . 11 3.5. Block Representation . . . . . . . . . . . . . . . . . . 10
3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 11 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 11
3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 14 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 14
3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 15 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 15
3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 16 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 16
3.10. Parameters and Result Types . . . . . . . . . . . . . . . 17 3.10. Cipher Suite Parameter and Result Identification . . . . 17
3.11. BSP Block Example . . . . . . . . . . . . . . . . . . . . 20 3.11. BSP Block Example . . . . . . . . . . . . . . . . . . . . 18
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 22 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Technical Notes . . . . . . . . . . . . . . . . . . . . . 22 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 20
4.2. Primary Block Canonicalization . . . . . . . . . . . . . 23 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 20
4.3. Non-Primary-Block Canonicalization . . . . . . . . . . . 23 5.1.1. Receiving BCB Blocks . . . . . . . . . . . . . . . . 20
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 24 5.1.2. Receiving BIB Blocks . . . . . . . . . . . . . . . . 21
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 24 5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 22
5.1.1. Receiving BCB Blocks . . . . . . . . . . . . . . . . 24 6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.2. Receiving BIB Blocks . . . . . . . . . . . . . . . . 25 7. Security Policy Considerations . . . . . . . . . . . . . . . 23
5.2. Bundle Fragmentation and Reassembly . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6. Key Management . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Attacker Capabilities and Objectives . . . . . . . . . . 24
7. Security Policy Considerations . . . . . . . . . . . . . . . 26 8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 25
8.1. Attacker Capabilities and Objectives . . . . . . . . . . 28 8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 26
8.2. Attacker Behaviors and BPSec Mitigations . . . . . . . . 29 8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 27
8.2.1. Eavesdropping Attacks . . . . . . . . . . . . . . . . 29 8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 27
8.2.2. Modification Attacks . . . . . . . . . . . . . . . . 29 9. Cipher Suite Authorship Considerations . . . . . . . . . . . 28
8.2.3. Topology Attacks . . . . . . . . . . . . . . . . . . 31 10. Defining Other Security Blocks . . . . . . . . . . . . . . . 29
8.2.4. Message Injection . . . . . . . . . . . . . . . . . . 31 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Cipher Suite Authorship Considerations . . . . . . . . . . . 32 11.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 30
10. Defining Other Security Blocks . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 34 12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . 31
12.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . 34 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This document defines security features for the Bundle Protocol (BP) This document defines security features for the Bundle Protocol (BP)
[BPBIS]. This BP Security Specification (BPSec) is intended for use [BPBIS] and is intended for use in Delay Tolerant Networks (DTNs) to
in Delay Tolerant Networks (DTNs) to provide end-to-end security provide end-to-end security services.
services.
1.1. Motivation
The Bundle Protocol specification [BPBIS] defines DTN as referring to The Bundle Protocol specification [BPBIS] defines DTN as referring to
"a networking architecture providing communications in and/or through "a networking architecture providing communications in and/or through
highly stressed environments" where "BP may be viewed as sitting at highly stressed environments" where "BP may be viewed as sitting at
the application layer of some number of constituent networks, forming the application layer of some number of constituent networks, forming
a store-carry-forward overlay network". The term "stressed" a store-carry-forward overlay network". The term "stressed"
environment refers to multiple challenging conditions including environment refers to multiple challenging conditions including
intermittent connectivity, large and/or variable delays, asymmetric intermittent connectivity, large and/or variable delays, asymmetric
data rates, and high bit error rates. data rates, and high bit error rates.
There is a reasonable expectation that BP may be deployed in such a The BP might be deployed such that portions of the network cannot be
way that a portion of the network might become compromised, posing trusted, posing the usual security challenges related to
the usual security challenges related to confidentiality and confidentiality and integrity. However, the stressed nature of the
integrity. However, the stressed nature of the BP operating BP operating environment imposes unique conditions where usual
environment imposes unique requirements such that the usual security transport security mechanisms may not be sufficient. For example,
mechanisms to usual security challenges may not apply. For example,
the store-carry-forward nature of the network may require protecting the store-carry-forward nature of the network may require protecting
data at rest while also preventing unauthorized consumption of data at rest, preventing unauthorized consumption of critical
critical resources such as storage space. The heterogeneous nature resources such as storage space, and operating without regular
of the networks comprising the BP overlay, and/or associated timing, contact with a centralized security oracle (such as a certificate
might prevent the establishment of an end-to-end session to provide a authority).
context for a security service. The partitionability of a DTN might
prevent regular contact with a centralized security oracle (such as a
certificate authority).
An end-to-end security service is needed that operates in all of the An end-to-end security service is needed that operates in all of the
environments where the BP operates. environments where the BP operates.
1.2. Supported Security Services 1.1. Supported Security Services
BPSec provides end-to-end integrity and confidentiality services for BPSec provides end-to-end integrity and confidentiality services for
BP bundles. BP bundles.
Integrity services ensure data within a bundle are not changed. Data Integrity services ensure that protected data within a bundle are not
changes may be caused by processing errors, environmental conditions, changed from the time they are provided to the network to the time
or intentional manipulation. An integrity service is one that they are delivered at their destination. Data changes may be caused
provides sufficient confidence to a data receiver that data has not by processing errors, environmental conditions, or intentional
changed since its value was last asserted. manipulation.
Confidentiality services ensure that only authorized receivers can Confidentiality services ensure that protected data is unintelligible
view those data within a bundle identified as needing to be private to nodes in the DTN, except for authorized nodes possessing special
amongst the data source and data receivers. A confidentiality information. Confidentiality, in this context, applies to the
services is one that provides confidence to a data receiver that contents of protected data and does not extend to hiding the fact
private data was not viewed by other nodes as the bundle traversed that protected data exist in the bundle.
the DTN.
NOTE: Hop-by-hop authentication is NOT a supported security service NOTE: Hop-by-hop authentication is NOT a supported security service
in this specification, for three reasons. in this specification, for three reasons.
1. The term "hop-by-hop" is ambiguous in a BP overlay, as nodes that 1. The term "hop-by-hop" is ambiguous in a BP overlay, as nodes that
are adjacent in the overlay may not be adjacent in physical are adjacent in the overlay may not be adjacent in physical
connectivity. This condition is difficult or impossible to connectivity. This condition is difficult or impossible to
predict in the overlay and therefore makes the concept of hop-by- detect and therefore hop-by-hop authentication is difficult or
hop authentication difficult or impossible to enforce at the impossible to enforce.
overlay.
2. Networks in which BPSec may be deployed may have a mixture of 2. Networks in which BPSec may be deployed may have a mixture of
security-aware and not-security-aware nodes. Hop-by-hop security-aware and not-security-aware nodes. Hop-by-hop
authentication cannot be deployed in a network if adjacent nodes authentication cannot be deployed in a network if adjacent nodes
in the network have different security capabilities. in the network have different security capabilities.
3. Hop-by-hop authentication can be viewed as a special case of data 3. Hop-by-hop authentication is a special case of data integrity and
integrity. As such, a version of authentication can be achieved can be achieved with the integrity mechanisms defined in this
by using the integrity mechanisms defined in this specification. specification. Therefore, a separate authentication service is
not necessary.
1.3. Specification Scope 1.2. Specification Scope
This document defines the security services provided by the BPSec. This document defines the security services provided by the BPSec.
This includes the data specification for representing these services This includes the data specification for representing these services
as BP extension blocks, and the rules for adding, removing, and as BP extension blocks, and the rules for adding, removing, and
processing these blocks at various points in the bundle's traversal processing these blocks at various points during the bundle's
of the DTN. traversal of the DTN.
BPSec applies only to those nodes that implement it, known as BPSec applies only to those nodes that implement it, known as
"security-aware" nodes. There might be other nodes in the DTN that "security-aware" nodes. There might be other nodes in the DTN that
do not implement BPSec. While all nodes in a BP overlay can exchange do not implement BPSec. While all nodes in a BP overlay can exchange
bundles, BPSec security operations can only happen at BPSec security- bundles, BPSec security operations can only happen at BPSec security-
aware nodes. aware nodes.
This specification does not address individual cipher suite This specification does not address individual cipher suite
implementations. Different networking conditions and operational implementations. Different networking conditions and operational
considerations require varying strengths of security mechanism such considerations require varying strengths of security mechanism such
that mandating a cipher suite in this specification may result in too that mandating a cipher suite in this specification may result in too
much security for some networks and too little security in others. much security for some networks and too little security in others.
The definition and enumeration of cipher suites is assumed to be It is expected that separate documents will be standardized to define
undertaken in other, separate specification documents. cipher suites compatible with BPSec, to include operational cipher
suites and interoperability cipher suites.
This specification does not address the implementation of security This specification does not address the implementation of security
policy and does not provide a security policy for the BPSec. Similar policy and does not provide a security policy for the BPSec. Similar
to cipher suites, security policies are based on the nature and to cipher suites, security policies are based on the nature and
capabilities of individual networks and network operational concepts. capabilities of individual networks and network operational concepts.
This specification does provide policy considerations when building a This specification does provide policy considerations when building a
security policy. security policy.
This specification does not address how to combine the BPSec security This specification does not address how to combine the BPSec security
blocks with other protocols, other BP extension blocks, or other best blocks with other protocols, other BP extension blocks, or other best
practices to achieve security in any particular network practices to achieve security in any particular network
implementation. implementation.
1.4. Related Documents 1.3. Related Documents
This document is best read and understood within the context of the This document is best read and understood within the context of the
following other DTN documents: following other DTN documents:
"Delay-Tolerant Networking Architecture" [RFC4838] defines the "Delay-Tolerant Networking Architecture" [RFC4838] defines the
architecture for DTNs and identifies certain security assumptions architecture for DTNs and identifies certain security assumptions
made by existing Internet protocols that are not valid in a DTN. made by existing Internet protocols that are not valid in a DTN.
The Bundle Protocol [BPBIS] defines the format and processing of the The Bundle Protocol [BPBIS] defines the format and processing of
bundles that both carry the data and the security services operating bundles, defines the extension block format used to represent BPSec
on those data. This document also defines the extension block format security blocks, and defines the canonicalization algorithms used by
used to capture BPSec security blocks. this specification.
The Bundle Security Protocol [RFC6257] and Streamlined Bundle The Bundle Security Protocol [RFC6257] and Streamlined Bundle
Security Protocol [SBSP] documents introduced the concepts of BP Security Protocol [SBSP] documents introduced the concepts of using
security blocks for security services in a DTN. The BPSec is a BP extension blocks for security services in a DTN. The BPSec is a
continuation and refinement of these documents. continuation and refinement of these documents.
1.5. Terminology 1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This section defines terminology either unique to the BPSec or This section defines terminology either unique to the BPSec or
otherwise necessary for understanding the concepts defined in this otherwise necessary for understanding the concepts defined in this
specification. specification.
o Bundle Source - the node which originates a bundle. The Node ID
of the BPA originating the bundle.
o Forwarder - any node that transmits a bundle in the DTN. The Node o Forwarder - any node that transmits a bundle in the DTN. The Node
ID of the Bundle Protocol Agent (BPA) that sent the bundle on its ID of the Bundle Protocol Agent (BPA) that sent the bundle on its
most recent hop. most recent hop.
o Intermediate Receiver, Waypoint, or "Next Hop" - any node that o Intermediate Receiver, Waypoint, or "Next Hop" - any node that
receives a bundle from a Forwarder that is not the Destination. receives a bundle from a Forwarder that is not the Destination.
The Node ID of the BPA at any such node. The Node ID of the BPA at any such node.
o Path - the ordered sequence of nodes through which a bundle passes o Path - the ordered sequence of nodes through which a bundle passes
on its way from Source to Destination. The path is not on its way from Source to Destination. The path is not
skipping to change at page 6, line 30 skipping to change at page 6, line 22
security target, notated as OP(security service, security target). security target, notated as OP(security service, security target).
For example, OP(confidentiality, payload). Every security For example, OP(confidentiality, payload). Every security
operation in a bundle MUST be unique, meaning that a 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. service can only be applied to a security target once in a bundle.
A security operation is implemented by a security block. A security operation is implemented by a security block.
o Security Service - the security features supported by this o Security Service - the security features supported by this
specification: integrity and confidentiality. specification: integrity and confidentiality.
o Security Source - a bundle node that adds a security block to a o Security Source - a bundle node that adds a security block to a
bundle. bundle. The Node ID of that node.
o Security Target - the block within a bundle that receives a o Security Target - the block within a bundle that receives a
security-service as part of a security-operation. security-service as part of a security-operation.
o Source - the node which originates a bundle. The Node ID of the 2. Design Decisions
BPA originating the bundle.
2. Key Properties
The application of security services in a DTN is a complex endeavor The application of security services in a DTN is a complex endeavor
that must consider physical properties of the network, policies at that must consider physical properties of the network, policies at
each node, and various application security requirements. This each node, and various application security requirements. This
section identifies and defines the key properties guiding design section identifies those desirable properties that guide design
decisions for the security services provided by this specification. decisions for this specification and are necessary for understanding
the format and behavior of the BPSec protocol.
2.1. Block-Level Granularity 2.1. Block-Level Granularity
Security services within this specification MUST allow different Security services within this specification MUST allow different
blocks within a bundle to have different security services applied to blocks within a bundle to have different security services applied to
them. As such, each security block within a bundle MUST be them.
associated with a specific security operation.
Blocks within a bundle represent different types of information. The Blocks within a bundle represent different types of information. The
primary block contains identification and routing information. The primary block contains identification and routing information. The
payload block carries application data. Extension blocks carry a payload block carries application data. Extension blocks carry a
variety of data that may augment or annotate the payload, or variety of data that may augment or annotate the payload, or
otherwise provide information necessary for the proper processing of otherwise provide information necessary for the proper processing of
a bundle along a path. Therefore, applying a single level and type a bundle along a path. Therefore, applying a single level and type
of security across an entire bundle fails to recognize that blocks in of security across an entire bundle fails to recognize that blocks in
a bundle may represent different types of information with different a bundle may represent different types of information with different
security needs. security needs.
skipping to change at page 8, line 28 skipping to change at page 8, line 18
Some waypoints may understand security blocks but refuse to process Some waypoints may understand security blocks but refuse to process
them unless they are the bundle destination. them unless they are the bundle destination.
2.4. User-Selected Cipher Suites 2.4. User-Selected Cipher Suites
The security services defined in this specification rely on a variety The security services defined in this specification rely on a variety
of cipher suites providing integrity signatures, cipher-text, and of cipher suites providing integrity signatures, cipher-text, and
other information necessary to populate security blocks. Users MAY other information necessary to populate security blocks. Users MAY
select different cipher suites to implement security services. For select different cipher suites to implement security services. For
example, some users might prefer a SHA-256 based hash for integrity example, some users might prefer a SHA2 hash function for integrity
whereas other users may prefer a SHA-384 hash instead. The security whereas other users may prefer a SHA3 hash function instead. The
services defined in this specification MUST provide a mechanism for security services defined in this specification MUST provide a
identifying what cipher suite has been used to populate a security mechanism for identifying what cipher suite has been used to populate
block. a security block.
2.5. Deterministic Processing 2.5. Deterministic Processing
Whenever a node determines that it must process more than one Whenever a node determines that it must process more than one
security block in a received bundle (either because the policy at a security block in a received bundle (either because the policy at a
waypoint states that it should process security blocks or because the waypoint states that it should process security blocks or because the
node is the bundle destination) the order in which security blocks node is the bundle destination) the order in which security blocks
are processed MUST be deterministic. All nodes MUST impose this same are processed MUST be deterministic. All nodes MUST impose this same
deterministic processing order for all security blocks. This deterministic processing order for all security blocks. This
specification provides determinism in the application and evaluation specification provides determinism in the application and evaluation
skipping to change at page 9, line 15 skipping to change at page 8, line 49
This specification defines two types of security block: the Block This specification defines two types of security block: the Block
Integrity Block (BIB) and the Block Confidentiality Block (BCB). Integrity Block (BIB) and the Block Confidentiality Block (BCB).
The BIB is used to ensure the integrity of its security target(s). The BIB is used to ensure the integrity of its security target(s).
The integrity information in the BIB MAY be verified by any node The integrity information in the BIB MAY be verified by any node
in between the BIB security source and the bundle destination. in between the BIB security source and the bundle destination.
Security-aware waypoints may add or remove BIBs from bundles in Security-aware waypoints may add or remove BIBs from bundles in
accordance with their security policy. accordance with their security policy.
The BCB indicates that the security target(s) has been encrypted, The BCB indicates that the security target(s) have been encrypted
in whole or in part, at the BCB security source in order to at the BCB security source in order to protect its content while
protect its content while in transit. The BCB may be decrypted by in transit. The BCB may be decrypted by security-aware nodes in
security-aware nodes in the network, up to and including the the network, up to and including the bundle destination, as a
bundle destination, as a matter of security policy. matter of security policy.
3.2. Uniqueness 3.2. Uniqueness
Security operations in a bundle MUST be unique - the same security Security operations in a bundle MUST be unique - the same security
service MUST NOT be applied to a security target more than once in a service MUST NOT be applied to a security target more than once in a
bundle. Since a security operation is represented as a security bundle. Since a security operation is represented as a security
block, this limits what security blocks may be added to a bundle: if block, this limits what security blocks may be added to a bundle: if
adding a security block to a bundle would cause some other security adding a security block to a bundle would cause some other security
block to no longer represent a unique security operation then the new block to no longer represent a unique security operation then the new
block MUST NOT be added. block MUST NOT be added.
If multiple security blocks representing the same security operation If multiple security blocks representing the same security operation
were allowed in a bundle at the same time, there would exist were allowed in a bundle at the same time, there would exist
ambiguity regarding block processing order and the property of ambiguity regarding block processing order and the property of
deterministic processing blocks would be lost. deterministic processing blocks would be lost.
Using the notation OP(service,target), several examples illustrate Using the notation OP(service,target), several examples illustrate
this uniqueness requirement. this uniqueness requirement.
o Signing the payload twice: The two operations OP(integrity, o Signing the payload twice: The two operations OP(integrity,
payload) and OP(integrity, payload) are redundant and cannot both payload) and OP(integrity, payload) are redundant and MUST NOT
be present in the same bundle at the same time. both be present in the same bundle at the same time.
o Signing different blocks: The two operations OP(integrity, o Signing different blocks: The two operations OP(integrity,
payload) and OP(integrity, extension_block_1) are not redundant payload) and OP(integrity, extension_block_1) are not redundant
and both may be present in the same bundle at the same time. and both may be present in the same bundle at the same time.
Similarly, the two operations OP(integrity, extension_block_1) and Similarly, the two operations OP(integrity, extension_block_1) and
OP(integrity,extension_block_2) are also not redundant and may OP(integrity,extension_block_2) are also not redundant and may
both be present in the bundle at the same time. both be present in the bundle at the same time.
o Different Services on same block: The two operations o Different Services on same block: The two operations
OP(integrity,payload) and OP(confidentiality, payload) are not OP(integrity,payload) and OP(confidentiality, payload) are not
inherently redundant and may both be present in the bundle at the inherently redundant and may both be present in the bundle at the
same time, pursuant to other processing rules in this same time, pursuant to other processing rules in this
specification. specification.
3.3. Target Multiplicity 3.3. Target Multiplicity
Under special circumstances, a single security block can represent Under special circumstances, a single security block may represent
multiple security operations as a way of reducing the overall number multiple security operations as a way of reducing the overall number
of security blocks present in a bundle. In these circumstances, of security blocks present in a bundle. In these circumstances,
reducing the number of security blocks in the bundle reduces the reducing the number of security blocks in the bundle reduces the
amount of redundant information in the bundle. amount of redundant information in the bundle.
A set of security operations may be represented by a single security A set of security operations may be represented by a single security
block if and only if the following conditions are true. block if and only if the following conditions are true.
o The security operations apply the same security service. For o The security operations apply the same security service. For
example, they are all integrity operations or all confidentiality example, they are all integrity operations or all confidentiality
skipping to change at page 10, line 50 skipping to change at page 10, line 36
When the security block is processed all security operations When the security block is processed all security operations
represented by the security block MUST be applied/evaluated at that represented by the security block MUST be applied/evaluated at that
time. time.
3.4. Target Identification 3.4. Target Identification
A security target is a block in the bundle to which a security A security target is a block in the bundle to which a security
service applies. This target MUST be uniquely and unambiguously service applies. This target MUST be uniquely and unambiguously
identifiable when processing a security block. The definition of the identifiable when processing a security block. The definition of the
extension block header from [BPBIS] provides a "Block Number" field extension block header from [BPBIS] provides a "Block Number" field
for exactly this purpose. Therefore, a security target in a security suitable for this purpose. Therefore, a security target in a
block MUST be represented as the Block Number of the target block. security block MUST be represented as the Block Number of the target
block.
3.5. Block Representation 3.5. Block Representation
Each security block uses the Canonical Bundle Block Format as defined Each security block uses the Canonical Bundle Block Format as defined
in [BPBIS]. That is, each security block is comprised of the in [BPBIS]. That is, each security block is comprised of the
following elements: following elements:
o Block Type Code o Block Type Code
o Block Number o Block Number
skipping to change at page 11, line 40 skipping to change at page 11, line 25
section defines an Abstract Security Block (ASB) data structure and section defines an Abstract Security Block (ASB) data structure and
discusses the definition, processing, and other constraints for using discusses the definition, processing, and other constraints for using
this structure. An ASB is never directly instantiated within a this structure. An ASB is never directly instantiated within a
bundle, it is only a mechanism for discussing the common aspects of bundle, it is only a mechanism for discussing the common aspects of
BIB and BCB security blocks. BIB and BCB security blocks.
The fields of the ASB SHALL be as follows, listed in the order in The fields of the ASB SHALL be as follows, listed in the order in
which they MUST appear. which they MUST appear.
Security Targets: Security Targets:
This field identifiers the block or blocks that are the target This field identifies the block(s) targetted by the security
of the security operation(s) represented by this security operation(s) represented by this security block. Each target
block. Each security target is identified as the Block Number block is represented by its unique Block Number. This field
of the target block. This field SHALL be represented by a CBOR SHALL be represented by a CBOR array of data items. Each
array of data items. Each target within this CBOR array SHALL target within this CBOR array SHALL be represented by a CBOR
be represented by a CBOR unsigned integer. This array MUST unsigned integer. This array MUST have at least 1 entry and
have at least 1 item. each entry MUST represent the Block Number of a block that
exists in the bundle. There MUST NOT be duplicate entries in
this array.
Cipher Suite Id: Cipher Suite Id:
This field identifies the cipher suite used to implement the This field identifies the cipher suite used to implement the
security service represented by this block and applied to each security service represented by this block and applied to each
security target. This field SHALL be represented by a CBOR security target. This field SHALL be represented by a CBOR
unsigned integer. unsigned integer.
Cipher Suite Flags: Cipher Suite Flags:
This field identifiers which optional fields are present in the This field identifies which optional fields are present in the
security block. This field SHALL be represented as a CBOR security block. This field SHALL be represented as a CBOR
unsigned integer containing a bit field of 5 bits indicating unsigned integer containing a bit field of 5 bits indicating
the presence or absence of other security block fields, as the presence or absence of other security block fields, as
follows. follows.
Bit 1 (the most-significant bit, 0x10): reserved. Bit 1 (the most-significant bit, 0x10): reserved.
Bit 2 (0x08): reserved. Bit 2 (0x08): reserved.
Bit 3 (0x04): reserved. Bit 3 (0x04): reserved.
skipping to change at page 12, line 44 skipping to change at page 12, line 33
array in accordance with [BPBIS] rules for representing array in accordance with [BPBIS] rules for representing
Endpoint Identifiers (EIDs). Endpoint Identifiers (EIDs).
Cipher Suite Parameters (Optional Field): Cipher Suite Parameters (Optional Field):
This field captures one or more cipher suite parameters that This field captures one or more cipher suite parameters that
should be provided to security-aware nodes when processing the should be provided to security-aware nodes when processing the
security service described by this security block. This field security service described by this security block. This field
SHALL be represented by a CBOR array. Each entry in this array SHALL be represented by a CBOR array. Each entry in this array
is a single cipher suite parameter. A single cipher suite is a single cipher suite parameter. A single cipher suite
parameter SHALL also be represented as a CBOR array comprising parameter SHALL also be represented as a CBOR array comprising
a 2-tuple of the type and value of the parameter, as follows. a 2-tuple of the id and value of the parameter, as follows.
* Parameter Type. This field identifiers which cipher suite * Parameter Id. This field identifies which cipher suite
parameter is being specified. This field SHALL be parameter is being specified. This field SHALL be
represented as a CBOR unsigned integer. Potential parameter represented as a CBOR unsigned integer. Parameter ids are
types are described in Section 3.10. Other specifications selected as described in Section 3.10.
MAY define additional parameter types for use in this field.
* Parameter Value. This field captures the value associated * Parameter Value. This field captures the value associated
with this parameter. This field SHALL be represented by the with this parameter. This field SHALL be represented by the
applicable CBOR representation of the parameter type. These applicable CBOR representation of the parameter, in
specifications are given in Section 3.10 for parameter types accordance with Section 3.10.
defined in this specification. Other specifications that
define other parameter types MUST include the appropriate
CBOR encoding of the parameter value.
Therefore, this field SHALL be represented as a CBOR array of The logical layout of the cipher suite parameters array is
CBOR arrays. illustrated in Figure 1.
+----------------+----------------+ +----------------+
| Parameter 1 | Parameter 2 | ... | Parameter N |
+------+---------+------+---------+ +------+---------+
| Id | Value | Id | Value | | Id | Value |
+------+---------+------+---------+ +------+---------+
Figure 1: Cipher Suite Parameters
Security Results: Security Results:
This field captures the results of applying a security service This field captures the results of applying a security service
to the security targets in this security block. This field to the security targets of the security block. This field
SHALL be represented as a CBOR array. Each entry in this array SHALL be represented as a CBOR array of target results. Each
represents a "target list" of security results for a specific entry in this array represents the set of security results for
security target. There MUST be one "target list" for each a specific security target. The target results MUST be ordered
entry in the Security Targets field and target lists in the identically to the Security Targets field of the security
Security Results field MUST be in the same order as the block. This means that the first set of target results in this
Security Targets field (e.g., the first "target list" MUST hold array corresponds to the first entry in the Security Targets
results for the first entry in the Security Targets field, and field of the security block, and so on. There MUST be one
so on). entry in this array for each entry in the Security Targets
field of the security block.
A "target list" is also represented as a CBOR array of The set of security results for a target is also represented as
individual security results for that target. An individual a CBOR array of individual results. An individual result is
security result is also represented as a CBOR array comprising represented as a 2-tuple of a result id and a result value,
the 2-tuple of the result type and result value, defined as defined as follows.
follows.
* Result Type. This field captures the type of security * Result Id. This field identifies which security result is
result. Some security result types capture the primary being specified. Some security results capture the primary
output of a cipher suite. Other security results contain output of a cipher suite. Other security results contain
additional annotative information from the cipher suite additional annotative information from cipher suite
processing. This field SHALL be represented as a CBOR processing. This field SHALL be represented as a CBOR
unsigned integer. Potential result types are described in unsigned integer. Security result ids will be as specified
Section 3.10. Other specifications MAY define additional in Section 3.10.
result types for use in this field.
* Result Value. This field captures the value associated with * Result Value. This field captures the value associated with
this result for this target. This field SHALL be the result. This field SHALL be represented by the
represented by the applicable CBOR representation of the applicable CBOR representation of the result value, in
result type. These specifications are given in Section 3.10 accordance with Section 3.10.
for result types defined in this specification. Other
specifications that define other result types MUST include The logical layout of the security results array is illustrated
the appropriate CBOR encoding of the result value. in Figure 2. In this figure there are N security targets for
this security block. The first security target contains M
results and the Nth security target contains K results.
+------------------------------+ +------------------------------+
| Target 1 | | Target N |
+------------+----+------------+ +------------------------------+
| Result 1 | | Result M | ... | Result 1 | | Result K |
+----+-------+ .. +----+-------+ +----+-------+ .. +----+-------+
| Id | Value | | Id | Value | | Id | Value | | Id | Value |
+----+-------+ +----+-------+ +----+-------+ +----+-------+
Figure 2: Security Results
3.7. Block Integrity Block 3.7. Block Integrity Block
A BIB is a bundle extension block with the following characteristics. A BIB is a bundle extension block with the following characteristics.
o The Block Type Code value is as specified in Section 12.1. o The Block Type Code value is as specified in Section 11.1.
o The Block Type Specific Data Fields follow the structure of the o The Block Type Specific Data Fields follow the structure of the
ASB. ASB.
o A security target listed in the Security Targets field MUST NOT o A security target listed in the Security Targets field MUST NOT
reference a security block defined in this specification (e.g., a reference a security block defined in this specification (e.g., a
BIB or a BCB). BIB or a BCB).
o The Cipher Suite Id MUST be documented as an end-to-end o The Cipher Suite Id MUST be documented as an end-to-end
authentication-cipher suite or as an end-to-end error-detection- authentication-cipher suite or as an end-to-end error-detection-
cipher suite. cipher suite.
o An EID-reference to the security source MAY be present. If this o An EID-reference to the security source MAY be present. If this
field is not present, then the security source of the block SHOULD field is not present, then the security source of the block SHOULD
be inferred according to security policy and MAY default to the be inferred according to security policy and MAY default to the
bundle source. The security source may also be specified as part bundle source. The security source may also be specified as part
of key information described in Section 3.10. of key information described in Section 3.10.
o The cipher suite MAY process less than the entire security target.
If the cipher suite processes less than the complete, original
security target, the cipher suite parameters MUST specify which
bytes of the security target are protected.
Notes: Notes:
o It is RECOMMENDED that cipher suite designers carefully consider o It is RECOMMENDED that cipher suite designers carefully consider
the effect of setting flags that either discard the block or the effect of setting flags that either discard the block or
delete the bundle in the event that this block cannot be delete the bundle in the event that this block cannot be
processed. processed.
o Since OP(integrity, target) is allowed only once in a bundle per o Since OP(integrity, target) is allowed only once in a bundle per
target, it is RECOMMENDED that users wishing to support multiple target, it is RECOMMENDED that users wishing to support multiple
integrity signatures for the same target define a multi-signature integrity signatures for the same target define a multi-signature
skipping to change at page 15, line 13 skipping to change at page 15, line 15
information, in accordance with Section 3.9. information, in accordance with Section 3.9.
o The use of a generally available key is RECOMMENDED if custodial o The use of a generally available key is RECOMMENDED if custodial
transfer is employed and all nodes SHOULD verify the bundle before transfer is employed and all nodes SHOULD verify the bundle before
accepting custody. accepting custody.
3.8. Block Confidentiality Block 3.8. Block Confidentiality Block
A BCB is a bundle extension block with the following characteristics. A BCB is a bundle extension block with the following characteristics.
The Block Type Code value is as specified in Section 12.1. The Block Type Code value is as specified in Section 11.1.
The Block Processing Control flags value can be set to whatever The Block Processing Control flags value can be set to whatever
values are required by local policy, except that this block MUST values are required by local policy, except that this block MUST
have the "replicate in every fragment" flag set if the target of have the "replicate in every fragment" flag set if the target of
the BCB is the Payload Block. Having that BCB in each fragment the BCB is the Payload Block. Having that BCB in each fragment
indicates to a receiving node that the payload portion of each indicates to a receiving node that the payload portion of each
fragment represents cipher-text. fragment represents cipher-text.
The Block Type Specific Data Fields follow the structure of the The Block Type Specific Data Fields follow the structure of the
ASB. ASB.
skipping to change at page 16, line 30 skipping to change at page 16, line 32
is larger than the plain-text, overflow bytes MUST be placed in is larger than the plain-text, overflow bytes MUST be placed in
overflow parameters in the Security Result field. overflow parameters in the Security Result field.
Notes: Notes:
o It is RECOMMENDED that cipher suite designers carefully consider o It is RECOMMENDED that cipher suite designers carefully consider
the effect of setting flags that either discard the block or the effect of setting flags that either discard the block or
delete the bundle in the event that this block cannot be delete the bundle in the event that this block cannot be
processed. processed.
o The cipher suite MAY process less than the entire original
security target body data. If the cipher suite processes less
than the complete, original security target body data, the BCB for
that security target MUST specify, as part of the cipher suite
parameters, which bytes of the body data are protected.
o The BCB block processing control flags MAY be set independently o The BCB block processing control flags MAY be set independently
from the processing control flags of the security target(s). The from the processing control flags of the security target(s). The
setting of such flags SHOULD be an implementation/policy decision setting of such flags SHOULD be an implementation/policy decision
for the encrypting node. for the encrypting node.
o A BCB MAY include information as part of additional authenticated o A BCB MAY include information as part of additional authenticated
data to address parts of the target block that are not converted data to address parts of the target block that are not converted
to cipher-text. to cipher-text.
3.9. Block Interactions 3.9. Block Interactions
skipping to change at page 17, line 45 skipping to change at page 17, line 40
security results. security results.
These restrictions on block interactions impose a necessary ordering These restrictions on block interactions impose a necessary ordering
when applying security operations within a bundle. Specifically, for when applying security operations within a bundle. Specifically, for
a given security target, BIBs MUST be added before BCBs. This a given security target, BIBs MUST be added before BCBs. This
ordering MUST be preserved in cases where the current BPA is adding ordering MUST be preserved in cases where the current BPA is adding
all of the security blocks for the bundle or whether the BPA is a all of the security blocks for the bundle or whether the BPA is a
waypoint adding new security blocks to a bundle that already contains waypoint adding new security blocks to a bundle that already contains
security blocks. security blocks.
3.10. Parameters and Result Types 3.10. Cipher Suite Parameter and Result Identification
Cipher suite parameters and security results may capture multiple
types of information in a security block. This section identifies a
set of parameters and results that are available in any BPSec
implementation for use by any cipher suite. Individual cipher suites
MAY define additional parameters and results. A cipher suite MAY
include multiple instances of the same type of parameter or result in
a security block.
Parameters and results are represented using CBOR, and any
identification of a new parameter or result type MUST include how the
value of the type will be represented using the CBOR specification.
Types themselves are always represented as a CBOR unsigned integer.
Cipher suite parameter types, as defined by this specification, are
as follows.
Cipher Suite Parameter Types.
+------+----------------+--------------------------+----------------+
| Type | Name | Description | CBOR |
| | | | Representation |
+------+----------------+--------------------------+----------------+
| 0 | Initialization | A random value, | Byte String |
| | Vector | typically eight to | |
| | | sixteen bytes. | |
+------+----------------+--------------------------+----------------+
| 1 | Key | Material encoded or | Byte String |
| | Information | protected by the key | |
| | | management system and | |
| | | used to transport an | |
| | | ephemeral key protected | |
| | | by a long-term key. | |
+------+----------------+--------------------------+----------------+
| 2 | Content Range | Pair of Unsigned | CBOR Array |
| | | Integers (offset,length) | comprising a |
| | | specifying the range of | 2-tuple of |
| | | payload bytes to which | CBOR unsigned |
| | | an operation applies. | integers. |
| | | The offset MUST be the | |
| | | offset within the | |
| | | original bundle, even if | |
| | | the current bundle is a | |
| | | fragment. | |
+------+----------------+--------------------------+----------------+
| 3 | Salt | An IV-like value used by | Byte Array |
| | | certain confidentiality | |
| | | suites. | |
+------+----------------+--------------------------+----------------+
| 4-31 | Reserved | Reserve for future BPSec | |
| | | protocol expansion | |
+------+----------------+--------------------------+----------------+
| >= | Unassigned | Unassigned by this | |
| 32 | | specification. Can be | |
| | | assigned by cipher suite | |
| | | specifications. | |
+------+----------------+--------------------------+----------------+
Table 1
Security result parameter types, as defined by this specification,
are as follows.
Security Result Types. Cipher suite parameters and security 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
security result ids are specified in the context of a cipher suite
definition.
+------+----------------+--------------------------+----------------+ Individual BPSec cipher suites SHOULD use existing registries of
| Type | Name | Description | CBOR | identifiers and CBOR encodings, such as those defined in [COSE],
| | | | Representation | whenever possible. Cipher suites MAY define their own identifiers
+------+----------------+--------------------------+----------------+ and CBOR encodings when necessary.
| 0 | Integrity | Result of BIB digest or | Byte String |
| | Signatures | other signing operation. | |
+------+----------------+--------------------------+----------------+
| 1 | BCB Integrity | Output from certain | Byte String |
| | Check Value | confidentiality cipher | |
| | (ICV) / | suite operations to be | |
| | Authentication | used at the destination | |
| | Tag | to verify that the | |
| | | protected data has not | |
| | | been modified. This | |
| | | value MAY contain | |
| | | padding if required by | |
| | | the cipher suite. | |
+------+----------------+--------------------------+----------------+
| 2-31 | Reserved | Reserve for future BPSec | |
| | | protocol expansion | |
+------+----------------+--------------------------+----------------+
| >= | Unassigned | Unassigned by this | |
| 32 | | specification. Can be | |
| | | assigned by cipher suite | |
| | | specifications. | |
+------+----------------+--------------------------+----------------+
Table 2 A cipher suite MAY include multiple instances of the same identifier
for a parameter or result in a security block. 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.
3.11. BSP Block Example 3.11. BSP Block Example
An example of BPSec blocks applied to a bundle is illustrated in An example of BPSec blocks applied to a bundle is illustrated in
Figure 1. In this figure the first column represents blocks within a Figure 3. In this figure the first column represents blocks within a
bundle and the second column represents the Block Number for the bundle and the second column represents the Block Number for the
block, using the terminology B1...Bn for the purpose of illustration. block, using the terminology B1...Bn for the purpose of illustration.
Block in Bundle ID Block in Bundle ID
+===================================+====+ +===================================+====+
| Primary Block | B1 | | Primary Block | B1 |
+-----------------------------------+----+ +-----------------------------------+----+
| BIB | B2 | | BIB | B2 |
| OP(integrity, target=B1) | | | OP(integrity, target=B1) | |
+-----------------------------------+----+ +-----------------------------------+----+
skipping to change at page 21, line 31 skipping to change at page 18, line 47
+-----------------------------------+----+ +-----------------------------------+----+
| BCB | B7 | | BCB | B7 |
| OP(confidentiality,targets=B8,B9) | | | OP(confidentiality,targets=B8,B9) | |
+-----------------------------------+----+ +-----------------------------------+----+
| BIB (encrypted by B7) | B8 | | BIB (encrypted by B7) | B8 |
| OP(integrity, target=B9) | | | OP(integrity, target=B9) | |
+-----------------------------------+----| +-----------------------------------+----|
| Payload Block | B9 | | Payload Block | B9 |
+-----------------------------------+----+ +-----------------------------------+----+
Figure 1: Sample Use of BPSec Blocks Figure 3: Sample Use of BPSec Blocks
In this example a bundle has four non-security-related blocks: the In this example a bundle has four non-security-related blocks: the
primary block (B1), two extension blocks (B4,B6), and a payload block primary block (B1), two extension blocks (B4,B6), and a payload block
(B9). The following security applications are applied to this (B9). The following security applications are applied to this
bundle. bundle.
o An integrity signature applied to the canonicalized primary block. o An integrity signature applied to the canonicalized primary block.
This is accomplished by a single BIB (B2). This is accomplished by a single BIB (B2).
o Confidentiality for the first extension block (B4). This is o Confidentiality for the first extension block (B4). This is
skipping to change at page 22, line 14 skipping to change at page 19, line 32
o Confidentiality for the payload block and it's integrity o Confidentiality for the payload block and it's integrity
signature. This is accomplished by a BCB block, B7, encrypting B8 signature. This is accomplished by a BCB block, B7, encrypting B8
and B9. In this case, the security source, key parameters, and and B9. In this case, the security source, key parameters, and
service are identical, so a single security block MAY be used for service are identical, so a single security block MAY be used for
this purpose, rather than requiring two BCBs one to encrypt B8 and this purpose, rather than requiring two BCBs one to encrypt B8 and
one to encrypt B9. one to encrypt B9.
4. Canonical Forms 4. Canonical Forms
By definition, an integrity service determines whether any aspect of Security services require consistency and determinism in how
a block was changed from the moment the security service was applied information is presented to cipher suites at the security source and
at the security source until the point of evaluation. To at a receiving node. For example, integrity services require that
successfully verify the integrity of a block, the data passed to the the same target information (e.g., the same bits in the same order)
verifying cipher suite MUST be the same bits, in the same order, as is provided to the cipher suite when generating an original signature
those passed to the signature-generating cipher suite at the security and when generating a comparison signature. Canonicalization
source. algorithms are used to construct a stable, end-to-end bit
representation of a target block.
This section provides guidance on how to create a canonical form for
each type of block in a bundle. This form MUST be used when
generating inputs to cipher suites for use by BPSec blocks.
4.1. Technical Notes
The following technical considerations hold for all canonicalizations
in this section.
o Any numeric fields defined as variable-length MUST be expanded to
their largest unpacked form before being used by a cipher suite.
If a field does not specify a maximum size, a maximum size of 32
bits for integer and 64 bits for floating point values SHALL be
assumed.
o Canonical forms are not transmitted, they are used to generate
input to a cipher suite for security processing at a security-
aware node.
o Reserved flags MUST NOT be included in any canonicalization as it
is not known if those flags will change in transit.
o 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.
o 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.
4.2. Primary Block Canonicalization
The canonicalization of the primary block is as specified in [BPBIS]
with the following exceptions.
o The following Bundle Processing Control Flags MAY change as a
bundle transits the DTN without indicating an integrity error and,
therefore, MUST NOT be included in the canonicalization of the
primary block.
* Bundle is a fragment. (Bit 15, 0x0001)
* Custody transfer requested for this bundle. (Bit 12, 0x0008)
* Reserved (Bits 0-2, 0xE000)
Regardless of the value of these flags in the primary block, they
MUST be set to 0 when canonicalized for security processing.
o The CRC field MAY change at each hop - for example, if a bundle Canonical forms are not transmitted, they are used to generate input
becomes fragmented, each fragment will have a different CRC value to a cipher suite for security processing at a security-aware node.
from the original signed primary block. As such, this field MUST
NOT be included in the canonicalization.
4.3. Non-Primary-Block Canonicalization The canonicalization of the primary block is as specified in [BPBIS].
All non-primary blocks (NPBs) share the same block structure and are All non-primary blocks share the same block structure and are
canonicalized as specified in [BPBIS] with the following exceptions. canonicalized as specified in [BPBIS] with the following exception.
o If the service being applied is a confidentiality service, then o If the service being applied is a confidentiality service, then
the Block Type Code, Block Number, Block Processing Control Flags, the Block Type Code, Block Number, Block Processing Control Flags,
CRC Type and CRC Field (if present), and Block Data Length fields CRC Type and CRC Field (if present), and Block Data Length fields
MUST NOT be included in the canonicalization. Confidentiality MUST NOT be included in the canonicalization. Confidentiality
services are used to convert the Block Type Specific Data Fields services are used solely to convert the Block Type Specific Data
from plain-text to cipher-text. Fields from plain-text to cipher-text.
o The Block Type Specific Data Field is included, without o Reserved flags MUST NOT be included in any canonicalization as it
modification, for both integrity and confidentiality services, is not known if those flags will change in transit.
with the exception that in some cases only a portion of the
payload data is to be processed. In such a case, only those bytes These canonicalization algorithms assume that Endpoint IDs do not
are included in the canonical form and additional cipher suite change from the time at which a security source adds a security block
parameters are required to specify which part of the field is to a bundle and the time at which a node processes that security
included. 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.
5. Security Processing 5. Security Processing
This section describes the security aspects of bundle processing. This section describes the security aspects of bundle processing.
5.1. Bundles Received from Other Nodes 5.1. Bundles Received from Other Nodes
Security blocks MUST be processed in a specific order when received Security blocks MUST be processed in a specific order when received
by a security-aware node. The processing order is as follows. by a security-aware node. The processing order is as follows.
skipping to change at page 24, line 38 skipping to change at page 21, line 7
directed to do so as a matter of security policy. directed to do so as a matter of security policy.
If the security policy of a security-aware node specifies that a If the security policy of a security-aware node specifies that a
bundle should have applied confidentiality to a specific security bundle should have applied confidentiality to a specific security
target and no such BCB is present in the bundle, then the node MUST target and no such BCB is present in the bundle, then the node MUST
process this security target in accordance with the security policy. process this security target in accordance with the security policy.
This MAY involve removing the security target from the bundle. If This MAY involve removing the security target from the bundle. If
the removed security target is the payload block, the bundle MAY be the removed security target is the payload block, the bundle MAY be
discarded. discarded.
If the relevant parts of an encrypted payload block cannot be If an encrypted payload block cannot be decrypted (i.e., the
decrypted (i.e., the decryption key cannot be deduced or decryption decryption key cannot be deduced or decryption fails), then the
fails), then the bundle MUST be discarded and processed no further. bundle MUST be discarded and processed no further. If an encrypted
If an encrypted security target other than the payload block cannot security target other than the payload block cannot be decrypted then
be decrypted then the associated security target and all security the associated security target and all security blocks associated
blocks associated with that target MUST be discarded and processed no with that target MUST be discarded and processed no further. In both
further. In both cases, requested status reports (see [BPBIS]) MAY cases, requested status reports (see [BPBIS]) MAY be generated to
be generated to reflect bundle or block deletion. reflect bundle or block deletion.
When a BCB is decrypted, the recovered plain-text MUST replace the When a BCB is decrypted, the recovered plain-text MUST replace the
cipher-text in the security target Block Type Specific Data Fields. cipher-text in the security target Block Type Specific Data Fields.
If the Block Data Length field was modified at the time of encryption If the Block Data Length field was modified at the time of encryption
it MUST be updated to reflect the decrypted block length. it MUST be updated to reflect the decrypted block length.
If a BCB contains multiple security targets, all security targets If a BCB contains multiple security targets, all security targets
MUST be processed when the BCB is processed. Errors and other MUST be processed when the BCB is processed. Errors and other
processing steps SHALL be made as if each security target had been processing steps SHALL be made as if each security target had been
represented by an individual BCB with a single security target. represented by an individual BCB with a single security target.
skipping to change at page 26, line 32 skipping to change at page 22, line 49
MAY be handled by other mechanisms outside of the BPSec protocol or MAY be handled by other mechanisms outside of the BPSec protocol or
by applying BPSec blocks in coordination with an encapsulation by applying BPSec blocks in coordination with an encapsulation
mechanism. mechanism.
6. Key Management 6. Key Management
There exist a myriad of ways to establish, communicate, and otherwise There exist a myriad of ways to establish, communicate, and otherwise
manage key information in a DTN. Certain DTN deployments might manage key information in a DTN. Certain DTN deployments might
follow established protocols for key management whereas other DTN follow established protocols for key management whereas other DTN
deployments might require new and novel approaches. BPSec assumes deployments might require new and novel approaches. BPSec assumes
that key management is handled as a separate part of network design that key management is handled as a separate part of network
and this specification neither defines nor requires a specific key management and this specification neither defines nor requires a
management strategy. specific key management strategy.
7. Security Policy Considerations 7. Security Policy Considerations
When implementing BPSec, several policy decisions must be considered. When implementing BPSec, several policy decisions must be considered.
This section describes key policies that affect the generation, This section describes key policies that affect the generation,
forwarding, and receipt of bundles that are secured using this forwarding, and receipt of bundles that are secured using this
specification. No single set of policy decisions is envisioned to specification. No single set of policy decisions is envisioned to
work for all secure DTN deployments. work for all secure DTN deployments.
o If a bundle is received that contains more than one security o If a bundle is received that contains more than one security
skipping to change at page 32, line 42 skipping to change at page 29, line 5
o Opportunistic Access: Depending on the application environment, a o Opportunistic Access: Depending on the application environment, a
given endpoint may not be guaranteed to be accessible within a given endpoint may not be guaranteed to be accessible within a
certain amount of time. This may make asymmetric cryptographic certain amount of time. This may make asymmetric cryptographic
architectures which rely on a key distribution center or other architectures which rely on a key distribution center or other
trust center impractical under certain conditions. trust center impractical under certain conditions.
When developing new cipher suites for use with BPSec, the following When developing new cipher suites for use with BPSec, the following
information SHOULD be considered for inclusion in these information SHOULD be considered for inclusion in these
specifications. specifications.
o New Parameters. Cipher suites MAY define new parameter types that o Cipher Suite Parameters. Cipher suites MUST define their
may appear in security blocks and used to configure the cipher parameter ids, the data types of those parameters, and their CBOR
suite. encoding.
o New Results. Cipher suites MAY define new security result types o Security Results. Cipher suites MUST define their security result
that may appear in security blocks and capture the outputs of the ids, the data types of those results, and their CBOR encoding.
cipher suite.
o New Canonicalizations. Cipher suites MAY define new o New Canonicalizations. Cipher suites MAY define new
canonicalization algorithms as necessary. canonicalization algorithms as necessary.
10. Defining Other Security Blocks 10. Defining Other Security Blocks
Other security blocks (OSBs) may be defined and used in addition to Other security blocks (OSBs) may be defined and used in addition to
the security blocks identified in this specification. Both the usage the security blocks identified in this specification. Both the usage
of BIB, BCB, and any future OSBs MAY co-exist within a bundle and MAY of BIB, BCB, and any future OSBs MAY co-exist within a bundle and MAY
be considered in conformance with BPSec if each of the following be considered in conformance with BPSec if each of the following
skipping to change at page 34, line 7 skipping to change at page 30, line 16
Additionally, policy considerations for the management, monitoring, Additionally, policy considerations for the management, monitoring,
and configuration associated with blocks SHOULD be included in any and configuration associated with blocks SHOULD be included in any
OSB definition. OSB definition.
NOTE: The burden of showing compliance with processing rules is NOTE: The burden of showing compliance with processing rules is
placed upon the standards defining new security blocks and the placed upon the standards defining new security blocks and the
identification of such blocks shall not, alone, require maintenance identification of such blocks shall not, alone, require maintenance
of this specification. of this specification.
11. Conformance 11. IANA Considerations
All implementations are strongly RECOMMENDED to provide some method
of hop-by-hop verification by generating a hash to some canonical
form of the bundle and placing an integrity signature on that form
using a BIB.
12. IANA Considerations
Registries of Cipher Suite IDs, Cipher Suite Flags, Cipher Suite A registry of cipher suite identifiers will be required.
Parameter Types, and Security Result Types will be required.
12.1. Bundle Block Types 11.1. Bundle Block Types
This specification allocates two block types from the existing This specification allocates two block types from the existing
"Bundle Block Types" registry defined in [RFC6255] . "Bundle Block Types" registry defined in [RFC6255] .
Additional Entries for the Bundle Block-Type Codes Registry: Additional Entries for the Bundle Block-Type Codes Registry:
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
| TBD | Block Integrity Block | This document | | TBD | Block Integrity Block | This document |
| TBD | Block Confidentiality Block | This document | | TBD | Block Confidentiality Block | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Table 3 Table 1
13. References 12. References
13.1. Normative References 12.1. Normative References
[BPBIS] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol", [BPBIS] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol",
draft-ietf-dtn-bpbis-06 (work in progress), July 2016. draft-ietf-dtn-bpbis-06 (work in progress), July 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>. <http://www.rfc-editor.org/info/rfc3552>.
[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol
IANA Registries", RFC 6255, May 2011. IANA Registries", RFC 6255, May 2011.
13.2. Informative References 12.2. Informative References
[COSE] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
draft-ietf-cose-msg-24 (work in progress), November 2016.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007. Networking Architecture", RFC 4838, April 2007.
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257, May "Bundle Security Protocol Specification", RFC 6257, May
2011. 2011.
[SBSP] Birrane, E., "Streamlined Bundle Security Protocol", [SBSP] Birrane, E., "Streamlined Bundle Security Protocol",
 End of changes. 73 change blocks. 
374 lines changed or deleted 243 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/