Bundle Protocol Security Specification
draft-ietf-dtn-bpsec-20
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9172.
|
|
|---|---|---|---|
| Authors | Edward J. Birrane , Kenneth McKeever | ||
| Last updated | 2020-02-07 | ||
| Replaces | draft-birrane-dtn-sbsp | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-12)
by Tim Evens
Ready w/nits
SECDIR Early review
(of
-06)
by Dan Harkins
Has issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Scott Burleigh | ||
| Shepherd write-up | Show Last changed 2019-06-19 | ||
| IESG | IESG state | Became RFC 9172 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Needs a YES. Needs 5 more YES or NO OBJECTION positions to pass. |
||
| Responsible AD | Magnus Westerlund | ||
| Send notices to | Scott Burleigh <Scott.C.Burleigh@jpl.nasa.gov> | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA expert review state | Expert Reviews OK | ||
| IANA expert review comments | An update on this assignment: we have converged on the registry questions in the new Bundle Protocol specification, agreeing to register new BPv7 block type numbers in the existing Bundle Block Types registry rather than starting up a new registry for BPv7 block types. This means that block type numbers 2 and 3 -- originally requested for the BPsec BIB and BCB blocks -- are not available (they are used by the old Bundle Authentication Block and Payload Integrity Block), so we must assign from one of the unassigned ranges. The BPbis specification requests that block types 11 and 12 be reserved for the Block Integrity Block and Block Confidentiality Block respectively, so those are the values that I would propose we assign. My understanding is that a slightly revised BPsec Internet Draft will be posted that simply requests that IANA assign numbers for these two blocks, without specifically asking for any particular values, so in the end I think there will be no conflict. |
draft-ietf-dtn-bpsec-20
o Other security blocks (OSBs) MUST NOT reuse any enumerations
identified in this specification, to include the block type codes
for BIB and BCB.
o An OSB definition MUST state whether it can be the target of a BIB
or a BCB. The definition MUST also state whether the OSB can
target a BIB or a BCB.
o An OSB definition MUST provide a deterministic processing order in
the event that a bundle is received containing BIBs, BCBs, and
OSBs. This processing order MUST NOT alter the BIB and BCB
processing orders identified in this specification.
o An OSB definition MUST provide a canonicalization algorithm if the
default non-primary-block canonicalization algorithm cannot be
used to generate a deterministic input for a cipher suite. This
requirement can be waived if the OSB is defined so as to never be
the security target of a BIB or a BCB.
o An OSB definition MUST NOT require any behavior of a BPSEC-BPA
that is in conflict with the behavior identified in this
specification. In particular, the security processing
requirements imposed by this specification must be consistent
across all BPSEC-BPAs in a network.
o The behavior of an OSB when dealing with fragmentation must be
specified and MUST NOT lead to ambiguous processing states. In
particular, an OSB definition should address how to receive and
process an OSB in a bundle fragment that may or may not also
contain its security target. An OSB definition should also
address whether an OSB may be added to a bundle marked as a
fragment.
Additionally, policy considerations for the management, monitoring,
and configuration associated with blocks SHOULD be included in any
OSB definition.
NOTE: The burden of showing compliance with processing rules is
placed upon the specifications defining new security blocks and the
identification of such blocks shall not, alone, require maintenance
of this specification.
11. IANA Considerations
This specification includes fields requiring registries managed by
IANA.
Birrane & McKeever Expires August 10, 2020 [Page 35]
Internet-Draft Bundle Protocol Security Specification February 2020
11.1. Bundle Block Types
This specification allocates two block types from the existing
"Bundle Block Types" registry defined in [RFC6255].
Additional Entries for the Bundle Block-Type Codes Registry:
+-------+-----------------------------+---------------+
| Value | Description | Reference |
+-------+-----------------------------+---------------+
| TBA | Block Integrity Block | This document |
| TBA | Block Confidentiality Block | This document |
+-------+-----------------------------+---------------+
Table 2
The Bundle Block Types namespace notes whether a block type is meant
for use in BP version 6, BP version 7, or both. The two block types
defined in this specification are meant for use with BP version 7.
11.2. Security Context Identifiers
BPSec has a Security Context Identifier field for which IANA is
requested to create and maintain a new registry named "BPSec Security
Context Identifiers". Initial values for this registry are given
below.
The registration policy for this registry is: Specification Required.
The value range is: unsigned 16-bit integer.
BPSec Security Context Identifier Registry
+-------+-------------+---------------+
| Value | Description | Reference |
+-------+-------------+---------------+
| 0 | Reserved | This document |
+-------+-------------+---------------+
Table 3
12. References
12.1. Normative References
Birrane & McKeever Expires August 10, 2020 [Page 36]
Internet-Draft Bundle Protocol Security Specification February 2020
[I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
Version 7", draft-ietf-dtn-bpbis-22 (work in progress),
February 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol
IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References
[I-D.birrane-dtn-sbsp]
Birrane, E., Pierce-Mayer, J., and D. Iannicca,
"Streamlined Bundle Security Protocol Specification",
draft-birrane-dtn-sbsp-01 (work in progress), October
2015.
[I-D.ietf-dtn-bpsec-interop-sc]
Birrane, E., "BPSec Interoperability Security Contexts",
draft-ietf-dtn-bpsec-interop-sc-01 (work in progress),
February 2020.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
Birrane & McKeever Expires August 10, 2020 [Page 37]
Internet-Draft Bundle Protocol Security Specification February 2020
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification", RFC 6257,
DOI 10.17487/RFC6257, May 2011,
<https://www.rfc-editor.org/info/rfc6257>.
Appendix A. Acknowledgements
The following participants contributed technical material, use cases,
and useful thoughts on the overall approach to this security
specification: Scott Burleigh of the Jet Propulsion Laboratory, Amy
Alford and Angela Hennessy of the Laboratory for Telecommunications
Sciences, and Angela Dalton and Cherita Corbett of the Johns Hopkins
University Applied Physics Laboratory.
Authors' Addresses
Edward J. Birrane, III
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
US
Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu
Kenneth McKeever
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
US
Phone: +1 443 778 2237
Email: Ken.McKeever@jhuapl.edu
Birrane & McKeever Expires August 10, 2020 [Page 38]