draft-ietf-dtn-bpsec-default-sc-03.txt   draft-ietf-dtn-bpsec-default-sc-04.txt 
Delay-Tolerant Networking E. Birrane Delay-Tolerant Networking E. Birrane
Internet-Draft JHU/APL Internet-Draft JHU/APL
Intended status: Standards Track March 28, 2021 Intended status: Standards Track April 11, 2021
Expires: September 29, 2021 Expires: October 13, 2021
BPSec Default Security Contexts BPSec Default Security Contexts
draft-ietf-dtn-bpsec-default-sc-03 draft-ietf-dtn-bpsec-default-sc-04
Abstract Abstract
This document defines default integrity and confidentiality security This document defines default integrity and confidentiality security
contexts that may be used with the Bundle Protocol Security Protocol contexts that may 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 35 skipping to change at page 1, line 35
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 September 29, 2021. This Internet-Draft will expire on October 13, 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 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Integrity Security Context BIB-HMAC-SHA2 . . . . . . . . . . 3 3. Integrity Security Context BIB-HMAC-SHA2 . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 6 3.3.1. SHA Variant . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. Encapsulated Key . . . . . . . . . . . . . . . . . . 6 3.3.2. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 6
3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 6 3.3.3. Integrity Scope Flags . . . . . . . . . . . . . . . . 7
3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 7 3.3.4. Enumerations . . . . . . . . . . . . . . . . . . . . 7
3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 8 3.5. Key Considerations . . . . . . . . . . . . . . . . . . . 8
3.6. Canonicalization Algorithms . . . . . . . . . . . . . . . 8 3.6. Canonicalization Algorithms . . . . . . . . . . . . . . . 8
3.7. Processing . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Processing . . . . . . . . . . . . . . . . . . . . . . . 9
3.7.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 9 3.7.1. Keyed Hash Generation . . . . . . . . . . . . . . . . 9
3.7.2. Keyed Hash Verification . . . . . . . . . . . . . . . 10 3.7.2. Keyed Hash Verification . . . . . . . . . . . . . . . 10
4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 11 4. Security Context BCB-AES-GCM . . . . . . . . . . . . . . . . 11
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 14 4.3.1. Initialization Vector (IV) . . . . . . . . . . . . . 14
4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 14 4.3.2. AES Variant . . . . . . . . . . . . . . . . . . . . . 14
4.3.3. Encapsulated Key . . . . . . . . . . . . . . . . . . 15 4.3.3. Wrapped Key . . . . . . . . . . . . . . . . . . . . . 15
4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 15 4.3.4. AAD Scope Flags . . . . . . . . . . . . . . . . . . . 15
4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 15 4.3.5. Enumerations . . . . . . . . . . . . . . . . . . . . 16
4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 16 4.4.1. Authentication Tag . . . . . . . . . . . . . . . . . 16
4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 17 4.4.2. Enumerations . . . . . . . . . . . . . . . . . . . . 17
4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 17 4.5. Key Considerations . . . . . . . . . . . . . . . . . . . 17
4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 18 4.6. GCM Considerations . . . . . . . . . . . . . . . . . . . 18
4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 18 4.7. Canonicalization Algorithms . . . . . . . . . . . . . . . 19
4.7.1. Cipher text related calculations . . . . . . . . . . 19 4.7.1. Cipher text related calculations . . . . . . . . . . 19
4.7.2. Additional Authenticated Data . . . . . . . . . . . . 19 4.7.2. Additional Authenticated Data . . . . . . . . . . . . 20
4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 20 4.8. Processing . . . . . . . . . . . . . . . . . . . . . . . 20
4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 20 4.8.1. Encryption . . . . . . . . . . . . . . . . . . . . . 20
4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 22 4.8.2. Decryption . . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5.1. Security Context Identifiers . . . . . . . . . . . . . . 23 5.1. Security Context Identifiers . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6.1. Key Handling . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Key Handling . . . . . . . . . . . . . . . . . . . . . . 24
6.2. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 24 6.3. Bundle Fragmentation . . . . . . . . . . . . . . . . . . 24
7. Normative References . . . . . . . . . . . . . . . . . . . . 25 7. Normative References . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec] The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec]
skipping to change at page 6, line 31 skipping to change at page 6, line 31
| 6 | HMAC 384/384 as defined in [RFC8152] Table 7: HMAC | | 6 | HMAC 384/384 as defined in [RFC8152] Table 7: HMAC |
| | Algorithm Values | | | Algorithm Values |
| 7 | HMAC 512/512 as defined in [RFC8152] Table 7: HMAC | | 7 | HMAC 512/512 as defined in [RFC8152] Table 7: HMAC |
| | Algorithm Values | | | Algorithm Values |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Table 1 Table 1
When not provided, implementations SHOULD assume a value of 6 When not provided, implementations SHOULD assume a value of 6
(indicating use of HMAC 384/384), unless an alternate default is (indicating use of HMAC 384/384), unless an alternate default is
established by security policy at the security source, verifiers, or established by local security policy at the security source,
acceptor of this integrity service. verifiers, or acceptor of this integrity service.
3.3.2. Encapsulated Key 3.3.2. Wrapped Key
This optional parameter contains the output of a Key Encapsulation This optional parameter contains the output of the AES key wrap
Mechanism (KEM) run at the security source of this security context. authenticated encryption function (KW-AE) as defined in [AES-KW].
Specifically, this parameter holds the cipher text produced when
running the KW-AE algorithm with the input string being the symmetric
HMAC key used to generate the security results present in the
security block. The value of this parameter is used as input to the
AES key wrap authenticated decryption function (KW-AD) at security
verifiers and security acceptors to determine the symmetric HMAC key
needed for the proper validation of the security results in the
security block.
This value MUST be encoded as a CBOR byte string. This value MUST be encoded as a CBOR byte string.
If provided, this information is used to retrieve the symmetric HMAC If this parameter is not present then security verifiers and
key used in the generation of security results for this security acceptors MUST determine the proper key as a function of their local
context. If not provided, security verifiers and acceptors MUST BPSec policy and configuration.
determine the proper key as a function of their local BPSec policy
and configuration, as discussed in Section 3.5.
3.3.3. Integrity Scope Flags 3.3.3. Integrity Scope Flags
This optional parameter contains a series of flags that describe what This optional parameter contains a series of flags that describe what
information is to be included with the block-type-specific data when information is to be included with the block-type-specific data when
constructing the IPPT value. constructing the IPPT value.
This value MUST be represented as a CBOR unsigned integer, the value This value MUST be represented as a CBOR unsigned integer, the value
of which MUST be processed as a bit field containing no more than 8 of which MUST be processed as a bit field containing no more than 8
bits. bits.
skipping to change at page 7, line 31 skipping to change at page 7, line 37
3.3.4. Enumerations 3.3.4. Enumerations
BIB-HMAC-SHA2 defines the following security context parameters. BIB-HMAC-SHA2 defines the following security context parameters.
BIB-HMAC-SHA2 Security Parameters BIB-HMAC-SHA2 Security Parameters
+----+-----------------------+--------------------+---------------+ +----+-----------------------+--------------------+---------------+
| Id | Name | CBOR Encoding Type | Default Value | | Id | Name | CBOR Encoding Type | Default Value |
+----+-----------------------+--------------------+---------------+ +----+-----------------------+--------------------+---------------+
| 1 | SHA Variant | UINT | 6 | | 1 | SHA Variant | UINT | 6 |
| 2 | Encapsulated Key | Byte String | NONE | | 2 | Wrapped Key | Byte String | NONE |
| 3 | Integrity Scope Flags | UINT | 0x7 | | 4 | Integrity Scope Flags | UINT | 0x7 |
+----+-----------------------+--------------------+---------------+ +----+-----------------------+--------------------+---------------+
Table 2 Table 2
3.4. Results 3.4. Results
BIB-HMAC-SHA2 defines the following security results. BIB-HMAC-SHA2 defines the following security results.
BIB-HMAC-SHA2 Security Results BIB-HMAC-SHA2 Security Results
skipping to change at page 8, line 21 skipping to change at page 8, line 21
+--------+----------+-------------+---------------------------------+ +--------+----------+-------------+---------------------------------+
| 1 | Expected | byte string | The output of the HMAC | | 1 | Expected | byte string | The output of the HMAC |
| | HMAC | | calculation at the security | | | HMAC | | calculation at the security |
| | | | source. | | | | | source. |
+--------+----------+-------------+---------------------------------+ +--------+----------+-------------+---------------------------------+
Table 3 Table 3
3.5. Key Considerations 3.5. Key Considerations
BIB-HMAC-SHA2 does not define or otherwise mandate any method for key
exchange, encryption, or encapsulation. The derivation of an
appropriate key for use in the integrity service is considered
separate from the application of the integrity service for this
context.
HMAC keys used with this context MUST be symmetric and MUST have a HMAC keys used with this context MUST be symmetric and MUST have a
key length equal to the output of the HMAC. key length equal to the output of the HMAC. For this reason, HMAC
keys will be integer divisible by 8 bytes and special padding-aware
AES key wrap algorithms are not needed.
It is assumed that any security verifier or security acceptor It is assumed that any security verifier or security acceptor
performing an integrity verification can determine the proper HMAC performing an integrity verification can determine the proper HMAC
key to be used. Potential sources of the HMAC key include (but are key to be used. Potential sources of the HMAC key include (but are
not limited to) the following: not limited to) the following:
Pre-placed keys selected based on local policy. Pre-placed keys selected based on local policy.
Keys extracted from encapsulated key material carried in the BIB. Keys extracted from material carried in the BIB.
Session keys negotiated via a mechanism external to the BIB. Session keys negotiated via a mechanism external to the BIB.
When an AES-KW wrapped key is present in a security block, it is
assumed that security verifiers and security acceptors can
independently determine the key encryption key (KEK) used in the
wrapping of the symmetric HMAC key.
As discussed in Section 6 and emphasized here, it is strongly As discussed in Section 6 and emphasized here, it is strongly
recommended that keys be protected once generated, both when they are recommended that keys be protected once generated, both when they are
stored and when they are transmitted. stored and when they are transmitted.
3.6. Canonicalization Algorithms 3.6. Canonicalization Algorithms
This section defines the canonicalization algorithm used to prepare This section defines the canonicalization algorithm used to prepare
the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The
construction of the IPPT depends on the settings of the integrity construction of the IPPT depends on the settings of the integrity
scope flags that may be provided as part of customizing the behavior scope flags that may be provided as part of customizing the behavior
skipping to change at page 10, line 27 skipping to change at page 10, line 27
MUST be updated as follows. These operations may occur in any order. MUST be updated as follows. These operations may occur in any order.
The security context identifier for the BIB MUST be set to the The security context identifier for the BIB MUST be set to the
context identifier for BIB-HMAC-SHA2. context identifier for BIB-HMAC-SHA2.
Any local flags used to generate the IPPT SHOULD be placed in the Any local flags used to generate the IPPT SHOULD be placed in the
integrity scope flags security parameter for the BIB unless these integrity scope flags security parameter for the BIB unless these
flags are expected to be correctly configured at security flags are expected to be correctly configured at security
verifiers and acceptors in the network. verifiers and acceptors in the network.
The HMAC key MAY be encapsulated using some key encapsulation The HMAC key MAY be wrapped using the NIST AES-KW algorithm and
mechanism (to include encrypting with a key encryption key) and the results of the wrapping added as the wrapped key security
the results of the encapsulation added as the encapsulated key parameter for the BIB.
security parameter for the BIB.
The SHA variant used by this security context SHOULD be added as The SHA variant used by this security context SHOULD be added as
the SHA variant security parameter for the BIB if it differs from the SHA variant security parameter for the BIB if it differs from
the default key length. Otherwise, this parameter MAY be omitted the default key length. Otherwise, this parameter MAY be omitted
if doing so provides a useful reduction in message sizes. if doing so provides a useful reduction in message sizes.
Problems encountered in the keyed hash generation MUST be processed Problems encountered in the keyed hash generation MUST be processed
in accordance with local BPSec security policy. in accordance with local BPSec security policy.
3.7.2. Keyed Hash Verification 3.7.2. Keyed Hash Verification
During keyed hash verification, the input of the security target and During keyed hash verification, the input of the security target and
a HMAC key are provided to the appropriate HMAC/SHA2 algorithm. a HMAC key are provided to the appropriate HMAC/SHA2 algorithm.
During keyed hash verification, two inputs are prepared for the During keyed hash verification, two inputs are prepared for the
appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT. These
data items MUST be generated as follows. data items MUST be generated as follows.
The HMAC key MUST be derived using the encapsulated key security The HMAC key MUST be derived using the wrapped key security
parameter if such a parameter is included in the security context parameter if such a parameter is included in the security context
parameters of the BIB. Otherwise, this key MUST be derived in parameters of the BIB. Otherwise, this key MUST be derived in
accordance with security policy at the verifying node as discussed accordance with security policy at the verifying node as discussed
in Section 3.5. in Section 3.5.
The IPPT MUST be generated as discussed in Section 3.6 with the The IPPT MUST be generated as discussed in Section 3.6 with the
value of integrity scope flags being taken from the integrity value of integrity scope flags being taken from the integrity
scope flags security context parameter. If the integrity scope scope flags security context parameter. If the integrity scope
flags parameter is not included in the security context parameters flags parameter is not included in the security context parameters
then these flags MAY be derived from local security policy. then these flags MAY be derived from local security policy.
skipping to change at page 12, line 20 skipping to change at page 12, line 20
Additionally, the BCB-AES-GCM security context generates an Additionally, the BCB-AES-GCM security context generates an
authentication tag based on the plain text value of the block-type- authentication tag based on the plain text value of the block-type-
specific data and other additional authenticated data that may be specific data and other additional authenticated data that may be
specified via parameters to this security context. specified via parameters to this security context.
This security context supports two variants of AES-GCM, based on the This security context supports two variants of AES-GCM, based on the
supported length of the symmetric key. These variants correspond to supported length of the symmetric key. These variants correspond to
A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm Value A128GCM and A256GCM as defined in [RFC8152] Table 9: Algorithm Value
for AES-GCM. for AES-GCM.
The BCB-AES-GCM security context shall have the security context The BCB-AES-GCM security context MUST have the security context
identifier specified in Section 5.1. identifier specified in Section 5.1.
4.2. Scope 4.2. Scope
There are two scopes associated with BCB-AES-GCM: the scope of the There are two scopes associated with BCB-AES-GCM: the scope of the
confidentiality service and the scope of the authentication service. confidentiality service and the scope of the authentication service.
The first defines the set of information provided to the AES-GCM The first defines the set of information provided to the AES-GCM
cipher for the purpose of producing cipher text. The second defines cipher for the purpose of producing cipher text. The second defines
the set of information used to generate an authentication tag. the set of information used to generate an authentication tag.
skipping to change at page 15, line 6 skipping to change at page 15, line 6
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Description | | Value | Description |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 1 | A128GCM as defined in [RFC8152] Table 9: Algorithm Values | | 1 | A128GCM as defined in [RFC8152] Table 9: Algorithm Values |
| | for AES-GCM | | | for AES-GCM |
| 3 | A256GCM as defined in [RFC8152] Table 9: Algorithm Values | | 3 | A256GCM as defined in [RFC8152] Table 9: Algorithm Values |
| | for AES-GCM | | | for AES-GCM |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
When not provided, implementations SHOULD assume a value of 3 When not provided, implementations SHOULD assume a value of 3
(indicating use of A256GCM), unless an alternate default is (indicating use of A256GCM), unless an alternate default is
established by security policy at the security source, verifier, or established by local security policy at the security source,
acceptor of this integrity service. verifier, or acceptor of this integrity service.
Regardless of the variant, the generated authentication tag MUST Regardless of the variant, the generated authentication tag MUST
always be 128 bits. always be 128 bits.
4.3.3. Encapsulated Key 4.3.3. Wrapped Key
This optional parameter contains the output of a Key Encapsulation This optional parameter contains the output of the AES key wrap
Mechanism (KEM) run at the security source of this security context. authenticated encryption function (KW-AE) as defined in [AES-KW].
Specifically, this parameter holds the cipher text produced when
running the KW-AE algorithm with the input string being the symmetric
AES key used to generate the security results present in the security
block. The value of this parameter is used as input to the AES key
wrap authenticated decryption function (KW-AD) at security verifiers
and security acceptors to determine the symmetric AES key needed for
the proper decryption of the security results in the security block.
This value MUST be encoded as a CBOR byte string. This value MUST be encoded as a CBOR byte string.
If provided, this information is used to retrieve the symmetric AES If this parameter is not present then security verifiers and
key used in the generation of security results for this security acceptors MUST determine the proper key as a function of their local
context. If not provided, security verifiers and acceptors MUST BPSec policy and configuration.
determine the proper key as a function of their local BPSec policy
and configuration, as discussed in Section 4.5.
4.3.4. AAD Scope Flags 4.3.4. AAD Scope Flags
This optional parameter contains a series of flags that describe what This optional parameter contains a series of flags that describe what
information is to be included with the block-type-specific data of information is to be included with the block-type-specific data of
the security target as part of additional authenticated data (AAD). the security target as part of additional authenticated data (AAD).
This value MUST be represented as a CBOR unsigned integer, the value This value MUST be represented as a CBOR unsigned integer, the value
of which MUST be processed as a bit field containing no more than 8 of which MUST be processed as a bit field containing no more than 8
bits. bits.
skipping to change at page 16, line 12 skipping to change at page 16, line 16
BCB-AES-GCM defines the following security context parameters. BCB-AES-GCM defines the following security context parameters.
BCB-AES-GCM Security Parameters BCB-AES-GCM Security Parameters
+----+-----------------------+--------------------+---------------+ +----+-----------------------+--------------------+---------------+
| Id | Name | CBOR Encoding Type | Default Value | | Id | Name | CBOR Encoding Type | Default Value |
+----+-----------------------+--------------------+---------------+ +----+-----------------------+--------------------+---------------+
| 1 | Initialization Vector | Byte String | NONE | | 1 | Initialization Vector | Byte String | NONE |
| 2 | AES Variant | UINT | 3 | | 2 | AES Variant | UINT | 3 |
| 3 | Encapsulation Key | Byte String | NONE | | 3 | Wrapped Key | Byte String | NONE |
| 4 | AAD Scope Flags | UINT | 0x7 | | 4 | AAD Scope Flags | UINT | 0x7 |
+----+-----------------------+--------------------+---------------+ +----+-----------------------+--------------------+---------------+
Table 4 Table 4
4.4. Results 4.4. Results
The BCB-AES-GCM security context produces a single security result The BCB-AES-GCM security context produces a single security result
carried in the security block: the authentication tag. carried in the security block: the authentication tag.
skipping to change at page 17, line 31 skipping to change at page 17, line 33
+-----------+--------------------+--------------------+ +-----------+--------------------+--------------------+
| Result Id | Result Name | CBOR Encoding Type | | Result Id | Result Name | CBOR Encoding Type |
+-----------+--------------------+--------------------+ +-----------+--------------------+--------------------+
| 1 | Authentication Tag | Byte String | | 1 | Authentication Tag | Byte String |
+-----------+--------------------+--------------------+ +-----------+--------------------+--------------------+
Table 5 Table 5
4.5. Key Considerations 4.5. Key Considerations
BCB-AES-GCM does not define or otherwise mandate any method for key
exchange, encryption, or encapsulation. The derivation of an
appropriate key is considered separate from the application of the
authenticated confidentiality service provided by this context.
Keys used with this context MUST be symmetric and MUST have a key Keys used with this context MUST be symmetric and MUST have a key
length equal to the key length defined in the security context length equal to the key length defined in the security context
parameters or as defined by local security policy at security parameters or as defined by local security policy at security
verifiers and acceptors. verifiers and acceptors. For this reason, content-encrypting keys
will be integer divisible by 8 bytes and special padding-aware AES
key wrap algorithms are not needed.
It is assumed that any security verifier or security acceptor can It is assumed that any security verifier or security acceptor can
determine the proper key to be used. Potential sources of the key determine the proper key to be used. Potential sources of the key
include (but are not limited to) the following. include (but are not limited to) the following.
Pre-placed keys selected based on local policy. Pre-placed keys selected based on local policy.
Keys extracted from encapsulated key material carried in the BCB. Keys extracted from material carried in the BCB.
Session keys negotiated via a mechanism external to the BCB. Session keys negotiated via a mechanism external to the BCB.
When an AES-KW wrapped key is present in a security block, it is
assumed that security verifiers and security acceptors can
independently determine the key encryption key (KEK) used in the
wrapping of the symmetric AES content-encrypting key.
The security provided by block ciphers is reduced as more data is The security provided by block ciphers is reduced as more data is
processed with the same key. The total number of bytes processed processed with the same key. The total number of bytes processed
with a single key for AES-GCM is recommended to be less than 2^64, as with a single key for AES-GCM is recommended to be less than 2^64, as
described in Appendix B of [AES-GCM]. described in Appendix B of [AES-GCM].
As discussed in Section 6 and emphasized here, it is strongly As discussed in Section 6 and emphasized here, it is strongly
recommended that keys be protected once generated, both when they are recommended that keys be protected once generated, both when they are
stored and when they are transmitted. stored and when they are transmitted.
4.6. GCM Considerations 4.6. GCM Considerations
skipping to change at page 21, line 44 skipping to change at page 22, line 5
The security context identifier for the BCB MUST be set to the The security context identifier for the BCB MUST be set to the
context identifier for BCB-AES-GCM. context identifier for BCB-AES-GCM.
The IV input to the cipher MUST be added as the IV security The IV input to the cipher MUST be added as the IV security
parameter for the BCB. parameter for the BCB.
Any local flags used to generated AAD for this cipher MUST be Any local flags used to generated AAD for this cipher MUST be
added as the AAD scope flags security parameter for the BCB. added as the AAD scope flags security parameter for the BCB.
The encryption key MAY be encapsulated using some key The encryption key MAY be wrapped using the NIST AES-KW algorithm
encapsulation mechanism (to include encrypting with a key and the results of the wrapping added as the wrapped key security
encryption key) and the results of the encapsulation added as the parameter for the BCB.
encapsulated key security parameter for the BCB.
The key length used by this security context MUST be considered The key length used by this security context MUST be considered
when setting the AES variant security parameter for the BCB if it when setting the AES variant security parameter for the BCB if it
differs from the default AES variant. Otherwise, the AES variant differs from the default AES variant. Otherwise, the AES variant
MAY be omitted if doing so provides a useful reduction in message MAY be omitted if doing so provides a useful reduction in message
sizes. sizes.
Problems encountered in the encryption MUST be processed in Problems encountered in the encryption MUST be processed in
accordance with local security policy. This MAY include restoring a accordance with local security policy. This MAY include restoring a
CRC value removed from the target block prior to encryption, if the CRC value removed from the target block prior to encryption, if the
target block is allowed to be transmitted after an encryption error. target block is allowed to be transmitted after an encryption error.
4.8.2. Decryption 4.8.2. Decryption
During encryption, five inputs are prepared for input to the AES/GCM During encryption, five inputs are prepared for input to the AES/GCM
cipher: the decryption key, the IV, the security target cipher text cipher: the decryption key, the IV, the security target cipher text
to be decrypted, any additional authenticated data, and the to be decrypted, any additional authenticated data, and the
authentication tag generated from the original encryption. These authentication tag generated from the original encryption. These
data items MUST be generated as follows. data items MUST be generated as follows.
The decryption key MUST be derived using the encapsulated key The decryption key MUST be derived using the wrapped key security
security parameter if such a parameter is included in the security parameter if such a parameter is included in the security context
context parameters of the BCB. Otherwise this key MUST be derived parameters of the BCB. Otherwise this key MUST be derived in
in accordance with security policy at the decrypting node as accordance with local security policy at the decrypting node as
discussed in Section 4.5. discussed in Section 4.5.
The IV MUST be set to the value of the IV security parameter The IV MUST be set to the value of the IV security parameter
included in the BCB. If the IV parameter is not included as a included in the BCB. If the IV parameter is not included as a
security parameter, an IV MAY be derived as a function of local security parameter, an IV MAY be derived as a function of local
security policy and other BCB contents or a lack of an IV security security policy and other BCB contents or a lack of an IV security
parameter in the BCB MAY be treated as an error by the decrypting parameter in the BCB MAY be treated as an error by the decrypting
node. node.
The security target cipher text for decryption MUST be generated The security target cipher text for decryption MUST be generated
skipping to change at page 24, line 22 skipping to change at page 24, line 31
It is strongly RECOMMENDED that implementations protect keys both It is strongly RECOMMENDED that implementations protect keys both
when they are stored and when they are transmitted. when they are stored and when they are transmitted.
In the event that a key is compromised, any security operations In the event that a key is compromised, any security operations
using a security context associated with that key SHOULD also be using a security context associated with that key SHOULD also be
considered compromised. This means that the BIB-HMAC-SHA2 considered compromised. This means that the BIB-HMAC-SHA2
security context SHOULD NOT provide integrity when used with a security context SHOULD NOT provide integrity when used with a
compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality
when used with a compromised key. when used with a compromised key.
When keys are extracted from key material carried in a security
block, the encapsulated key SHOULD be protected by an approved
algorithm such as NIST SP-800-38F. The determination to use
approved algorithms increases interoperability and the specific
algorithm used is expected to be specified as part of local
security policy.
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 may leak information about the key. so may leak information about the key.
Unless otherwise specified, the security contexts provided in this
document do not mandate any specific method for key exchange,
encryption, or encapsulation. The derivation of an appropriate
key is considered separate from the application of the
authenticated confidentiality service provided by this context.
6.2. AES GCM 6.2. 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.
6.3. Bundle Fragmentation 6.3. Bundle Fragmentation
Bundle fragmentation may prevent security services in a bundle from Bundle fragmentation may prevent security services in a bundle from
skipping to change at page 25, line 31 skipping to change at page 25, line 38
bound to a bundle, then a fragmenting BPA should consider bound to a bundle, then a fragmenting BPA should consider
encapsulating the bundle first and then fragmenting the encapsulating encapsulating the bundle first and then fragmenting the encapsulating
bundle. bundle.
7. Normative References 7. Normative References
[AES-GCM] Dworkin, M., "NIST Special Publication 800-38D: [AES-GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation: Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC.", November 2007. Galois/Counter Mode (GCM) and GMAC.", November 2007.
[AES-KW] Dworkin, M., "NIST Special Publication 800-38F:
Recommendation for Block Cipher Modes of Operation:
Methods for Key Wrapping.", December 2012.
[HMAC] US NIST, "The Keyed-Hash Message Authentication Code [HMAC] US NIST, "The Keyed-Hash Message Authentication Code
(HMAC).", FIPS-198-1, Gaithersburg, MD, USA, July 2008. (HMAC).", FIPS-198-1, Gaithersburg, MD, USA, July 2008.
https://csrc.nist.gov/publications/detail/fips/198/1/final https://csrc.nist.gov/publications/detail/fips/198/1/final
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
Version 7", draft-ietf-dtn-bpbis-31 (work in progress), Version 7", draft-ietf-dtn-bpbis-31 (work in progress),
January 2021. January 2021.
 End of changes. 35 change blocks. 
70 lines changed or deleted 85 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/