draft-ietf-dtn-bpsec-09.txt   draft-ietf-dtn-bpsec-10.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: August 25, 2019 February 21, 2019 Expires: October 11, 2019 April 9, 2019
Bundle Protocol Security Specification Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-09 draft-ietf-dtn-bpsec-10
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 25, 2019. This Internet-Draft will expire on October 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8 2.3. Mixed Security Policy . . . . . . . . . . . . . . . . . . 8
2.4. User-Defined Security Contexts . . . . . . . . . . . . . 8 2.4. User-Defined Security Contexts . . . . . . . . . . . . . 8
2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9 2.5. Deterministic Processing . . . . . . . . . . . . . . . . 9
3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9 3.1. Block Definitions . . . . . . . . . . . . . . . . . . . . 9
3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10 3.3. Target Multiplicity . . . . . . . . . . . . . . . . . . . 10
3.4. Target Identification . . . . . . . . . . . . . . . . . . 11 3.4. Target Identification . . . . . . . . . . . . . . . . . . 11
3.5. Block Representation . . . . . . . . . . . . . . . . . . 11 3.5. Block Representation . . . . . . . . . . . . . . . . . . 11
3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12 3.6. Abstract Security Block . . . . . . . . . . . . . . . . . 12
3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 14 3.7. Block Integrity Block . . . . . . . . . . . . . . . . . . 15
3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 15 3.8. Block Confidentiality Block . . . . . . . . . . . . . . . 16
3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17 3.9. Block Interactions . . . . . . . . . . . . . . . . . . . 17
3.10. Parameter and Result Identification . . . . . . . . . . . 18 3.10. Parameter and Result Identification . . . . . . . . . . . 18
3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 18 3.11. BSP Block Examples . . . . . . . . . . . . . . . . . . . 18
3.11.1. Example 1: Constructing a Bundle with Security . . . 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 3.11.2. Example 2: Adding More Security At A New Node . . . 20
4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 21 4. Canonical Forms . . . . . . . . . . . . . . . . . . . . . . . 21
5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22 5. Security Processing . . . . . . . . . . . . . . . . . . . . . 22
5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22 5.1. Bundles Received from Other Nodes . . . . . . . . . . . . 22
5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22 5.1.1. Receiving BCBs . . . . . . . . . . . . . . . . . . . 22
5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23 5.1.2. Receiving BIBs . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 3, line 45 skipping to change at page 3, line 45
authority). 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.1. 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, as defined in this section. BP bundles, as defined in this section.
Integrity services ensure that target data within a bundle are not Integrity services ensure that changes to target data within a
changed from the time they are provided to the network to the time bundle, if any, can be discovered. Data changes may be caused by
they are delivered at their destination. Data changes may be caused processing errors, environmental conditions, or intentional
by processing errors, environmental conditions, or intentional
manipulation. In the context of BPSec, integrity services apply to manipulation. In the context of BPSec, integrity services apply to
plain-text in the bundle. plain-text in the bundle.
Confidentiality services ensure that target data is unintelligible to Confidentiality services ensure that target data is unintelligible to
nodes in the DTN, except for authorized nodes possessing special nodes in the DTN, except for authorized nodes possessing special
information. This generally means producing cipher-text from plain- information. This generally means producing cipher-text from plain-
text and generating authentication information for that cipher-text. text and generating authentication information for that cipher-text.
Confidentiality, in this context, applies to the contents of target Confidentiality, in this context, applies to the contents of target
data and does not extend to hiding the fact that confidentiality data and does not extend to hiding the fact that confidentiality
exists in the bundle. exists in the bundle.
skipping to change at page 5, line 45 skipping to change at page 5, line 44
"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 [I-D.ietf-dtn-bpbis] defines the format and The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and
processing of bundles, defines the extension block format used to processing of bundles, defines the extension block format used to
represent BPSec security blocks, and defines the canonicalization represent BPSec security blocks, and defines the canonicalization
algorithms used by this specification. algorithms used by this specification.
The Concise Binary Object Representation (CBOR) format [RFC7049]
defines a data format that allows for small code size, fairly small
message size, and extensibility without version negotiation. The
block-specific data associated with BPSec security blocks are encoded
in this data format.
The Bundle Security Protocol [RFC6257] and Streamlined Bundle The Bundle Security Protocol [RFC6257] and Streamlined Bundle
Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the Security Protocol [I-D.birrane-dtn-sbsp] documents introduced the
concepts of using BP extension blocks for security services in a DTN. concepts of using BP extension blocks for security services in a DTN.
The BPSec is a continuation and refinement of these documents. The BPSec is a continuation and refinement of these documents.
1.4. 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
skipping to change at page 18, line 14 skipping to change at page 18, line 22
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.
NOTE: Since any cipher suite used with a BCB MUST be an AEAD cipher NOTE: Since any cipher suite used with a BCB MUST be an AEAD cipher
suite, it is inefficient and possible insecure for a single security 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 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 cases where a security source wishes to calculate both a plain-text
integrity mechanism and encrypt a security target, a BCB with a integrity mechanism and encrypt a security target, a BCB with a
cipher suite that generates such signatures as additional security cipher suite that generates such signatures as additional security
results SHOULD be used instead. results SHOULD be used instead.
3.10. Parameter and Result Identification 3.10. Parameter and Result Identification
Security context parameters and results each represent multiple Security context parameters and results each represent multiple
distinct pieces of information in a security block. Each piece of distinct pieces of information in a security block. Each piece of
skipping to change at page 34, line 19 skipping to change at page 34, line 19
[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,
<https://www.rfc-editor.org/info/rfc3552>. <https://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, DOI 10.17487/RFC6255, May IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May
2011, <https://www.rfc-editor.org/info/rfc6255>. 2011, <https://www.rfc-editor.org/info/rfc6255>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
12.2. Informative References 12.2. Informative References
[I-D.birrane-dtn-sbsp] [I-D.birrane-dtn-sbsp]
Birrane, E., Pierce-Mayer, J., and D. Iannicca, Birrane, E., Pierce-Mayer, J., and D. Iannicca,
"Streamlined Bundle Security Protocol Specification", "Streamlined Bundle Security Protocol Specification",
draft-birrane-dtn-sbsp-01 (work in progress), October draft-birrane-dtn-sbsp-01 (work in progress), October
2015. 2015.
[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
 End of changes. 8 change blocks. 
10 lines changed or deleted 19 lines changed or added

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