draft-ietf-dtn-bpsec-default-sc-07.txt   draft-ietf-dtn-bpsec-default-sc-08.txt 
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft A. White Internet-Draft A. White
Intended status: Standards Track S. Heiner Intended status: Standards Track S. Heiner
Expires: November 18, 2021 JHU/APL Expires: December 10, 2021 JHU/APL
May 17, 2021 June 8, 2021
BPSec Default Security Contexts BPSec Default Security Contexts
draft-ietf-dtn-bpsec-default-sc-07 draft-ietf-dtn-bpsec-default-sc-08
Abstract Abstract
This document defines default integrity and confidentiality security This document defines default integrity and confidentiality security
contexts that can be used with the Bundle Protocol Security Protocol contexts that can be used with the Bundle Protocol Security Protocol
(BPSec) implementations. These security contexts are intended to be (BPSec) implementations. These security contexts are intended to be
used for both testing the interoperability of BPSec implementations used for both testing the interoperability of BPSec implementations
and for providing basic security operations when no other security and for providing basic security operations when no other security
contexts are defined or otherwise required for a network. contexts are defined or otherwise required for a network.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 November 18, 2021. This Internet-Draft will expire on December 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 3, line 6 skipping to change at page 3, line 6
4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 23 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 23
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
5.1. Security Context Identifiers . . . . . . . . . . . . . . 24 5.1. Security Context Identifiers . . . . . . . . . . . . . . 24
5.2. Integrity Scope Flags . . . . . . . . . . . . . . . . . . 25 5.2. Integrity Scope Flags . . . . . . . . . . . . . . . . . . 25
5.3. AAD Scope Flags . . . . . . . . . . . . . . . . . . . . . 25 5.3. AAD Scope Flags . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 26 6.1. Key Management . . . . . . . . . . . . . . . . . . . . . 26
6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 27 6.2. Key Handling . . . . . . . . . . . . . . . . . . . . . . 27
6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.3. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 28 6.4. AES Key Wrap . . . . . . . . . . . . . . . . . . . . . . 28
6.5. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 28 6.5. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 29
7. Normative References . . . . . . . . . . . . . . . . . . . . 29 7. Normative References . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 30
A.1. Example 1: Simple Integrity . . . . . . . . . . . . . . . 31 A.1. Example 1: Simple Integrity . . . . . . . . . . . . . . . 31
A.1.1. Original Bundle . . . . . . . . . . . . . . . . . . . 31 A.1.1. Original Bundle . . . . . . . . . . . . . . . . . . . 31
A.1.2. Security Operation Overview . . . . . . . . . . . . . 33 A.1.2. Security Operation Overview . . . . . . . . . . . . . 33
A.1.3. Bundle Integrity Block . . . . . . . . . . . . . . . 33 A.1.3. Bundle Integrity Block . . . . . . . . . . . . . . . 34
A.1.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 35 A.1.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 35
A.2. Example 2: Simple Confidentiality with Key Wrap . . . . . 35 A.2. Example 2: Simple Confidentiality with Key Wrap . . . . . 35
A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 35 A.2.1. Original Bundle . . . . . . . . . . . . . . . . . . . 35
A.2.2. Security Operation Overview . . . . . . . . . . . . . 36 A.2.2. Security Operation Overview . . . . . . . . . . . . . 36
A.2.3. Bundle Confidentiality Block . . . . . . . . . . . . 37 A.2.3. Bundle Confidentiality Block . . . . . . . . . . . . 37
A.2.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 39 A.2.4. Final Bundle . . . . . . . . . . . . . . . . . . . . 39
A.3. Example 3: Security Blocks from Multiple Sources . . . . 39 A.3. Example 3: Security Blocks from Multiple Sources . . . . 39
A.3.1. Original Bundle . . . . . . . . . . . . . . . . . . . 39 A.3.1. Original Bundle . . . . . . . . . . . . . . . . . . . 39
A.3.2. Security Operation Overview . . . . . . . . . . . . . 41 A.3.2. Security Operation Overview . . . . . . . . . . . . . 41
A.3.3. Bundle Integrity Block . . . . . . . . . . . . . . . 41 A.3.3. Bundle Integrity Block . . . . . . . . . . . . . . . 41
skipping to change at page 17, line 42 skipping to change at page 17, line 42
NOTES: NOTES:
The cipher text generated by the cipher suite is not considered a The cipher text generated by the cipher suite is not considered a
security result as it is stored in the block-type-specific data security result as it is stored in the block-type-specific data
field of the security target block. When operating in GCM mode, field of the security target block. When operating in GCM mode,
AES produces cipher text of the same size as its plain text and, AES produces cipher text of the same size as its plain text and,
therefore, no additional logic is required to handle padding or therefore, no additional logic is required to handle padding or
overflow caused by the encryption in most cases (see below). overflow caused by the encryption in most cases (see below).
If the generated cipher text contains the authentication tag and If the authentication tag can be separated from the cipher text,
the tag can be separated from the cipher text then the tag MUST be then the tag MAY be separated and stored in the authentication tag
separated and stored in the authentication tag security result security result field. Otherwise, the security target block MUST
field. be resized to accommodate the additional 128 bits of
authentication tag included with the generated cipher text
If the generated cipher text contains the authentication tag and replacing the block-type-specific-data field of the security
the tag cannot be separated from the cipher text then the tag MUST target block.
NOT be included in the authentication tag security result field.
Instead the security target block MUST be resized to accommodate
the additional 128 bits of authentication tag included in the
generated cipher text.
4.4.1. Authentication Tag 4.4.1. Authentication Tag
The authentication tag is generated by the cipher suite over the The authentication tag is generated by the cipher suite over the
security target plain text input to the cipher suite as combined with security target plain text input to the cipher suite as combined with
any optional additional authenticated data. This tag is used to any optional additional authenticated data. This tag is used to
ensure that the plain text (and important information associated with ensure that the plain text (and important information associated with
the plain text) is authenticated prior to decryption. the plain text) is authenticated prior to decryption.
If the authentication tag is included in the cipher text placed in If the authentication tag is included in the cipher text placed in
skipping to change at page 24, line 35 skipping to change at page 24, line 35
If the cipher text fails to authenticate, if any needed parameters If the cipher text fails to authenticate, if any needed parameters
are missing, or if there are other problems in the decryption then are missing, or if there are other problems in the decryption then
the decryption MUST be treated as failed and processed in accordance the decryption MUST be treated as failed and processed in accordance
with local security policy. with local security policy.
5. IANA Considerations 5. IANA Considerations
5.1. Security Context Identifiers 5.1. Security Context Identifiers
This specification allocates two security context identifiers from This specification allocates two security context identifiers from
the "BPSec Security Context Identifier" registry defined in the "BPSec Security Context Identifiers" registry defined in
[I-D.ietf-dtn-bpsec]. [I-D.ietf-dtn-bpsec].
Additional Entries for the BPSec Security Context Identifiers Additional Entries for the BPSec Security Context Identifiers
Registry: Registry:
+-------+---------------+---------------+ +-------+---------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------+---------------+ +-------+---------------+---------------+
| TBA | BIB-HMAC-SHA2 | This document | | TBA | BIB-HMAC-SHA2 | This document |
| TBA | BCB-AES-GCM | This document | | TBA | BCB-AES-GCM | This document |
+-------+---------------+---------------+ +-------+---------------+---------------+
Table 7 Table 7
5.2. Integrity Scope Flags 5.2. Integrity Scope Flags
The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field
for which IANA is requested to create and maintain a new registry for which IANA is requested to create and maintain a new registry
named "BPSec BIB-HMAC-SHA2 Integrity Scope Flags." Initial values named "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the Bundle
for this registry are given below. Protocol registry page. Initial values for this registry are given
below.
The registration policy for this registry is: Specification Required. The registration policy for this registry is: Specification Required.
The value range is unsigned 16-bit integer. The value range is unsigned 16-bit integer.
BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry
+-------------------------+--------------------------+--------------+ +-------------------------+--------------------------+--------------+
| Bit Position (right to | Description | Reference | | Bit Position (right to | Description | Reference |
| left) | | | | left) | | |
skipping to change at page 25, line 40 skipping to change at page 25, line 41
| 8-15 | unassigned | This | | 8-15 | unassigned | This |
| | | document | | | | document |
+-------------------------+--------------------------+--------------+ +-------------------------+--------------------------+--------------+
Table 8 Table 8
5.3. AAD Scope Flags 5.3. AAD Scope Flags
The BCB-AES-GCM security context has an AAD Scope Flags field for The BCB-AES-GCM security context has an AAD Scope Flags field for
which IANA is requested to create and maintain a new registry named which IANA is requested to create and maintain a new registry named
"BPSec BCB-AES-GCM AAD Scope Flags." Initial values for this "BPSec BCB-AES-GCM AAD Scope Flags" on the Bundle Protocol registry
registry are given below. page. Initial values for this registry are given below.
The registration policy for this registry is: Specification Required. The registration policy for this registry is: Specification Required.
The value range is unsigned 16-bit integer. The value range is unsigned 16-bit integer.
BPSec BCB-AES-GCM AAD Scope Flags Registry BPSec BCB-AES-GCM AAD Scope Flags Registry
+-------------------------+--------------------------+--------------+ +-------------------------+--------------------------+--------------+
| Bit Position (right to | Description | Reference | | Bit Position (right to | Description | Reference |
| left) | | | | left) | | |
skipping to change at page 28, line 22 skipping to change at page 28, line 22
The same key SHOULD NOT be used for different algorithms as doing The same key SHOULD NOT be used for different algorithms as doing
so might leak information about the key. so might leak information about the key.
6.3. AES GCM 6.3. AES GCM
There are a significant number of considerations related to the use There are a significant number of considerations related to the use
of the GCM mode of AES to provide a confidentiality service. These of the GCM mode of AES to provide a confidentiality service. These
considerations are provided in Section 4.6 as part of the considerations are provided in Section 4.6 as part of the
documentation of the BCB-AES-GCM security context. documentation of the BCB-AES-GCM security context.
It should be noted that the authentication tag produced by the GCM The length of the cipher text produced by the GCM mode of AES will be
mode of AES is not considered part of the cipher text itself. While equal to the length of the plain text input to the cipher suite. The
certain implementations might catenate the authentication tag and the authentication tag also produced by this cipher suite is separate
produced cipher text, they are distinct values. For this reason, the from the cipher text. However, it should be noted that
authentication tag is expected to be carried in the BCB-AES-GCM implementations of the AES-GCM cipher suite might not separate the
security block as a security result whenever the authentication tag concept of cipher text and authentication tag in their application
can be differentiated from the produced cipher text. programming interface (API).
Implementations of the BCB-AES-GCM security context can either keep
the length of the target block unchanged by holding the
authentication tag in a BCB security result or alter the length of
the target block by including the authentication tag with the cipher
text replacing the block-type-specific-data field of the target
block. Implementations MAY use the authentication tag security
result in cases where keeping target block length unchanged is an
important processing concern. In all cases, the cipher text and
authentication tag MUST be processed in accordance with the API of
the AES-GCM cipher suites at the security source and security
acceptor.
6.4. AES Key Wrap 6.4. AES Key Wrap
The AES key wrap (AES-KW) algorithm used by the security contexts in The AES key wrap (AES-KW) algorithm used by the security contexts in
this document does not use an initialization vector and does not this document does not use an initialization vector and does not
require any key padding. Key padding is not needed because wrapped require any key padding. Key padding is not needed because wrapped
keys used by these security contexts will always be multiples of 8 keys used by these security contexts will always be multiples of 8
bytes. The length of the wrapped key can be determined by inspecting bytes. The length of the wrapped key can be determined by inspecting
the security context parameters. Therefore, a key can be unwrapped the security context parameters. Therefore, a key can be unwrapped
using only the information present in the security block and the key using only the information present in the security block and the key
skipping to change at page 30, line 18 skipping to change at page 30, line 28
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
[SHS] US NIST, "Secure Hash Standard (SHS).", FIPS- [SHS] US NIST, "Secure Hash Standard (SHS).", FIPS-
180-4, Gaithersburg, MD, USA, August 2015. 180-4, Gaithersburg, MD, USA, August 2015.
https://csrc.nist.gov/publications/detail/fips/180/4/final https://csrc.nist.gov/publications/detail/fips/180/4/final
skipping to change at page 30, line 49 skipping to change at page 31, line 14
suites for individual implementations as well as interoperability suites for individual implementations as well as interoperability
test suites amongst implementations. However, these examples do not test suites amongst implementations. However, these examples do not
cover every permutation of security parameters, security results, or cover every permutation of security parameters, security results, or
use of security blocks in a bundle. use of security blocks in a bundle.
NOTE: Figures in this section identified as "(CBOR Diagnostic NOTE: Figures in this section identified as "(CBOR Diagnostic
Notation)" are represented using the CBOR diagnostic notation defined Notation)" are represented using the CBOR diagnostic notation defined
in [RFC8949]. This notation is used to express CBOR data structures in [RFC8949]. This notation is used to express CBOR data structures
in a manner that enables visual inspection. The bundles, security in a manner that enables visual inspection. The bundles, security
blocks, and security context contents in these figures are blocks, and security context contents in these figures are
represented using CBOR structures. represented using CBOR structures. In cases where BP blocks (to
include BPSec security blocks) are comprised of a sequence of CBOR
objects, these objects are represented as a CBOR sequence as defined
in [RFC8742].
NOTE: Examples in this section use the "ipn" URI scheme for NOTE: Examples in this section use the "ipn" URI scheme for
EndpointID naming, as defined in [I-D.ietf-dtn-bpbis]. EndpointID naming, as defined in [I-D.ietf-dtn-bpbis].
NOTE: The bundle source is presumed to be the security source for all NOTE: The bundle source is presumed to be the security source for all
security blocks in this section, unless otherwise noted. security blocks in this section, unless otherwise noted.
A.1. Example 1: Simple Integrity A.1. Example 1: Simple Integrity
This example shows the addition of a BIB to a sample bundle to This example shows the addition of a BIB to a sample bundle to
 End of changes. 12 change blocks. 
30 lines changed or deleted 46 lines changed or added

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