draft-ietf-acme-dtnnodeid-03.txt   draft-ietf-acme-dtnnodeid-04.txt 
Automated Certificate Management Environment B. Sipos Automated Certificate Management Environment B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Intended status: Experimental 3 May 2021 Updates: -ietf-dtn-bpbis (if approved) 6 June 2021
Expires: 4 November 2021 Intended status: Experimental
Expires: 8 December 2021
Automated Certificate Management Environment (ACME) Delay-Tolerant Automated Certificate Management Environment (ACME) Delay-Tolerant
Networking (DTN) Node ID Validation Extension Networking (DTN) Node ID Validation Extension
draft-ietf-acme-dtnnodeid-03 draft-ietf-acme-dtnnodeid-04
Abstract Abstract
This document specifies an extension to the Automated Certificate This document specifies an extension to the Automated Certificate
Management Environment (ACME) protocol which allows an ACME server to Management Environment (ACME) protocol which allows an ACME server to
validate the Delay-Tolerant Networking (DTN) Node ID for an ACME validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
client. The DTN Node ID is encoded as a certificate Subject client. The DTN Node ID is encoded as a certificate Subject
Alternative Name (SAN) of type Uniform Resource Identifier (URI) and Alternative Name (SAN) of type Uniform Resource Identifier (URI) and
ACME Identifier type "uri". ACME Identifier type "uri".
skipping to change at page 1, line 36 skipping to change at page 1, line 37
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 4 November 2021. This Internet-Draft will expire on 8 December 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 33 skipping to change at page 2, line 33
3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 10 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 10
3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 11 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 11
3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 12 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 12
3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 13 3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 13
3.4. ACME Node ID Validation Response Bundles . . . . . . . . 13 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 13
3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 15 3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 15
4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 15 4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 15
5. Certificate Request Profile . . . . . . . . . . . . . . . . . 16 5. Certificate Request Profile . . . . . . . . . . . . . . . . . 16
5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 16 5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 16
5.2. Generating Encryption-only or Signing-only Bundle Security 5.2. Generating Encryption-only or Signing-only Bundle Security
Certificates . . . . . . . . . . . . . . . . . . . . . . 17 Certificates . . . . . . . . . . . . . . . . . . . . . . 16
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 6. Bundle Protocol Administrative Record Types Registry . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
7.1. Threat: Passive Leak of Validation Data . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 18 8.1. Threat: Passive Leak of Validation Data . . . . . . . . . 18
7.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 18 8.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 18
7.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 19 8.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 19
8.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.2. ACME Validation Method . . . . . . . . . . . . . . . . . 20 9.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 20
8.3. BP Bundle Administrative Record Types . . . . . . . . . . 20 9.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9.3. Bundle Administrative Record Types . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Administrative Record Types CDDL . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix B. Example Authorization . . . . . . . . . . . . . . . 24 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 25
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Example Authorization . . . . . . . . . . . . . . . 25
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 25 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Although the original purpose of the Automatic Certificate Management Although the original purpose of the Automatic Certificate Management
Environment (ACME) [RFC8555] was to allow Public Key Infrastructure Environment (ACME) [RFC8555] was to allow Public Key Infrastructure
Using X.509 (PKIX) certificate authorities to validate network domain Using X.509 (PKIX) certificate authorities to validate network domain
names of clients, the same mechanism can be used to validate any of names of clients, the same mechanism can be used to validate any of
the subject claims supported by the PKIX profile [RFC5280]. the subject claims supported by the PKIX profile [RFC5280].
In the case of this specification, the claim being validated is a In the case of this specification, the claim being validated is a
skipping to change at page 3, line 35 skipping to change at page 3, line 37
can contain multiple identifiers of multiple types, there can be can contain multiple identifiers of multiple types, there can be
operational issues for a client attempting to, and possibly failing operational issues for a client attempting to, and possibly failing
to, validate those multiple identifiers as described in Section 5.1. to, validate those multiple identifiers as described in Section 5.1.
Once a certificate is issued for a Node ID, how the ACME client Once a certificate is issued for a Node ID, how the ACME client
configures the Bundle Protocol (BP) agent with the new certificate is configures the Bundle Protocol (BP) agent with the new certificate is
an implementation matter. an implementation matter.
The scope and behavior of this validation mechanism is similar to The scope and behavior of this validation mechanism is similar to
that of secured email validation of [RFC8823]. that of secured email validation of [RFC8823].
This document also updates BPv7 to explicitly use the IANA
administrative record type registry in Section 6.
1.1. Scope 1.1. Scope
This document describes the ACME messages, BPv7 payloads, and BPSec This document describes the ACME messages, BPv7 payloads, and BPSec
requirements needed to validate Node ID ownership. This document requirements needed to validate Node ID ownership. This document
does not address: does not address:
* Mechanisms for communication between ACME client or ACME server * Mechanisms for communication between ACME client or ACME server
and their associated BP agent(s). This document only describes and their associated BP agent(s). This document only describes
exchanges between ACME client--server pairs and between their BP exchanges between ACME client--server pairs and between their BP
agents. agents.
skipping to change at page 5, line 19 skipping to change at page 5, line 24
diagram of Figure 1 and defined in Section 3. diagram of Figure 1 and defined in Section 3.
+------------+ +------------+ +------------+ +------------+
| ACME |<===== HTTPS exchanges =====>| ACME | | ACME |<===== HTTPS exchanges =====>| ACME |
| Client | | Server | | Client | | Server |
+------------+ +------------+ +------------+ +------------+
| | ^ | | ^
Enable or disable Send | | Enable or disable Send | |
challenge from server Challenge | | Indicate challenge from server Challenge | | Indicate
| Non-DTN | | Response | Non-DTN | | Response
-------------------------------------------------------------------- ~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~|~~~~~~~~~~
V DTN V | V DTN V |
++------------++ ++------------++ ++------------++ ++------------++
|| Admin Elem.|| || Admin Elem.|| || Admin Elem.|| || Admin Elem.||
|+------------+| |+------------+| |+------------+| |+------------+|
| Client's |<----- Challenge Bundle ---| Server's | | Client's |<----- Challenge Bundle ---| Server's |
| BP Agent | | BP Agent | | BP Agent | | BP Agent |
+--------------+ +--------------+ +--------------+ +--------------+
| ^ | ^
| +-------------+ | | +-------------+ |
| | Integrity | | | | Integrity | |
skipping to change at page 11, line 44 skipping to change at page 11, line 44
meant to indicate any node-specific path delays expected to meant to indicate any node-specific path delays expected to
encountered from the ACME server. Because there is no requirement on encountered from the ACME server. Because there is no requirement on
the path (or paths) which bundles may traverse between the ACME the path (or paths) which bundles may traverse between the ACME
server and the BP agent, and the ACME server can attempt some path server and the BP agent, and the ACME server can attempt some path
diversity, the RTT value SHOULD be pessimistic. diversity, the RTT value SHOULD be pessimistic.
A default bundle response interval, used when the object does not A default bundle response interval, used when the object does not
contain an RTT, SHOULD be a configurable parameter of the ACME contain an RTT, SHOULD be a configurable parameter of the ACME
server. If the ACME client indicated an RTT value in the object, the server. If the ACME client indicated an RTT value in the object, the
response interval SHOULD be twice the RTT (with limiting logic response interval SHOULD be twice the RTT (with limiting logic
applied as described below). The lower limit on response waiting applied as described below). The lower limit on response interval is
time is network-specific, but SHOULD NOT be shorter than one second. network-specific, but SHOULD NOT be shorter than one second. The
The upper limit on response waiting time is network-specific, but upper limit on response interval is network-specific, but SHOULD NOT
SHOULD NOT be longer than one minute (60 seconds) for a terrestrial- be longer than one minute (60 seconds) for a terrestrial-only DTN.
only DTN.
3.3. ACME Node ID Validation Challenge Bundles 3.3. ACME Node ID Validation Challenge Bundles
Each Each ACME Node ID Validation Challenge Bundle SHALL be Each Each ACME Node ID Validation Challenge Bundle SHALL be
structured and encoded in accordance with [I-D.ietf-dtn-bpbis]. structured and encoded in accordance with [I-D.ietf-dtn-bpbis].
Each Challenge Bundle has parameters as listed here: Each Challenge Bundle has parameters as listed here:
Bundle Processing Control Flags: The primary block flags SHALL Bundle Processing Control Flags: The primary block flags SHALL
indicate that the payload is an administrative record. The indicate that the payload is an administrative record. The
skipping to change at page 12, line 33 skipping to change at page 12, line 33
Source Node ID: The Source Node ID SHALL indicate the Node ID of the Source Node ID: The Source Node ID SHALL indicate the Node ID of the
ACME server performing the challenge. ACME server performing the challenge.
Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set
to the time at which the challenge was generated. The Lifetime to the time at which the challenge was generated. The Lifetime
SHALL indicate the response interval for which ACME server will SHALL indicate the response interval for which ACME server will
accept responses to this challenge. accept responses to this challenge.
Administrative Record Type Code: Set to the ACME Node ID Validation Administrative Record Type Code: Set to the ACME Node ID Validation
type code defined in Section 8.3. type code defined in Section 9.3.
Administrative Record Content: The Challenge Bundle administrative Administrative Record Content: The Challenge Bundle administrative
record content SHALL consist of a CBOR map containing two pairs: record content SHALL consist of a CBOR map containing two pairs:
* One pair SHALL consist of key 1 with value of ACME challenge * One pair SHALL consist of key 1 with value of ACME challenge
"token-chal", copied from the challenge object, represented as "token-chal", copied from the challenge object, represented as
a CBOR byte string. a CBOR byte string.
* One pair SHALL consist of key 2 with value of ACME challenge * One pair SHALL consist of key 2 with value of ACME challenge
"token-bundle", represented as a CBOR byte string. The "token- "token-bundle", represented as a CBOR byte string. The "token-
skipping to change at page 13, line 13 skipping to change at page 13, line 13
example full Challenge Bundle is included in Appendix B.1 example full Challenge Bundle is included in Appendix B.1
If the BP agent generating a Challenge Bundle does not have a well- If the BP agent generating a Challenge Bundle does not have a well-
synchronized clock or the agent responding to the challenge is synchronized clock or the agent responding to the challenge is
expected to not have a well-synchronized clock, the bundle SHALL expected to not have a well-synchronized clock, the bundle SHALL
include a Bundle Age extension block. include a Bundle Age extension block.
Challenge Bundles SHALL include a Block Integrity Block (BIB) in Challenge Bundles SHALL include a Block Integrity Block (BIB) in
accordance with Section 4 or with a Security Source identical to the accordance with Section 4 or with a Security Source identical to the
bundle Source Node. Challenge Bundles SHALL NOT be directly bundle Source Node. Challenge Bundles SHALL NOT be directly
encrypted by Block Confidentiality Block (BCB) or any other method encrypted by Block Confidentiality Block (BCB) or any other method
(see Section 7.1). (see Section 8.1).
3.3.1. Challenge Bundle Checks 3.3.1. Challenge Bundle Checks
A proper Challenge Bundle meets all of the following criteria: A proper Challenge Bundle meets all of the following criteria:
* The Challenge Bundle was received within the time interval allowed * The Challenge Bundle was received within the time interval allowed
for the challenge. for the challenge.
* The Challenge Bundle Source Node ID is identical to the Node ID * The Challenge Bundle Source Node ID is identical to the Node ID
indicated in the ACME challenge object. The comparison of Node indicated in the ACME challenge object. The comparison of Node
skipping to change at page 14, line 25 skipping to change at page 14, line 25
Source Node ID: The Source Node ID SHALL be identical to the the Source Node ID: The Source Node ID SHALL be identical to the the
Destination EID of the Challenge Bundle to which this response Destination EID of the Challenge Bundle to which this response
corresponds. corresponds.
Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set
to the time at which the response was generated. The response to the time at which the response was generated. The response
Lifetime SHALL indicate the response interval remaining if the Lifetime SHALL indicate the response interval remaining if the
Challenge Bundle indicated a limited Lifetime. Challenge Bundle indicated a limited Lifetime.
Administrative Record Type Code: Set to the ACME Node ID Validation Administrative Record Type Code: Set to the ACME Node ID Validation
type code defined in Section 8.3. type code defined in Section 9.3.
Administrative Record Content: The Response Bundle administrative Administrative Record Content: The Response Bundle administrative
record content SHALL consist of a CBOR map containing three pairs: record content SHALL consist of a CBOR map containing three pairs:
* One pair SHALL consist of key 1 with value of ACME challenge * One pair SHALL consist of key 1 with value of ACME challenge
"token-chal", copied from the Request Bundle, represented as a "token-chal", copied from the Request Bundle, represented as a
CBOR byte string. CBOR byte string.
* One pair SHALL consist of key 2 with value of ACME challenge * One pair SHALL consist of key 2 with value of ACME challenge
"token-bundle", copied from the Request Bundle, represented as "token-bundle", copied from the Request Bundle, represented as
skipping to change at page 15, line 7 skipping to change at page 15, line 7
This structure is part of the extension CDDL in Appendix A. An This structure is part of the extension CDDL in Appendix A. An
example full Response Bundle is included in Appendix B.2 example full Response Bundle is included in Appendix B.2
If the BP agent responding to a Challenge Bundle does not have a If the BP agent responding to a Challenge Bundle does not have a
well-synchronized clock, it SHALL use any information about last-hop well-synchronized clock, it SHALL use any information about last-hop
delays and (if present) Bundle Age extension data to infer the age of delays and (if present) Bundle Age extension data to infer the age of
the Challenge Bundle and lifetime of the Response Bundle. the Challenge Bundle and lifetime of the Response Bundle.
Response Bundles SHALL include a BIB in accordance with Section 4. Response Bundles SHALL include a BIB in accordance with Section 4.
Response Bundles SHALL NOT be directly encrypted by BCB or any other Response Bundles SHALL NOT be directly encrypted by BCB or any other
method (see Section 7.1 for explanation). method (see Section 8.1 for explanation).
3.4.1. Response Bundle Checks 3.4.1. Response Bundle Checks
A proper Response Bundle meets all of the following criteria: A proper Response Bundle meets all of the following criteria:
* The Response Bundle was received within the time interval allowed * The Response Bundle was received within the time interval allowed
for the challenge. for the challenge.
* The Response Bundle Source Node ID is identical to the Node ID * The Response Bundle Source Node ID is identical to the Node ID
being validated. The comparison of Node IDs SHALL use the being validated. The comparison of Node IDs SHALL use the
skipping to change at page 15, line 32 skipping to change at page 15, line 32
primary block and payload. That BIB has a security source which primary block and payload. That BIB has a security source which
is trusted and passes security-context-specific validation. is trusted and passes security-context-specific validation.
* The response payload contains the "token-chal" and "token-bundle" * The response payload contains the "token-chal" and "token-bundle"
as sent in the Challenge Bundle. The response payload contains as sent in the Challenge Bundle. The response payload contains
the expected Key Authorization digest computed by the ACME server. the expected Key Authorization digest computed by the ACME server.
Because multiple Challenge Bundles can be sent to validate the Because multiple Challenge Bundles can be sent to validate the
same Node ID, the "token-bundle" in the response is needed to same Node ID, the "token-bundle" in the response is needed to
correlate with the expected Key Authorization digest. correlate with the expected Key Authorization digest.
Any of the failures above SHALL cause the validation to fail. Any of Any of the failures above SHALL cause the validation to fail with an
the failures above SHOULD be indicated as subproblems to the ACME ACME error type of "incorrectResponse". Any of the failures above
client. SHOULD be indicated as subproblems to the ACME client. The lack of a
response within the expected response interval, as defined in
Section 3.2, SHALL also be treated as a validation failure.
4. Bundle Integrity Gateway 4. Bundle Integrity Gateway
This section defines a BIB use which closely resembles the function This section defines a BIB use which closely resembles the function
of DKIM email signing [RFC6376]. In this mechanism a routing node in of DKIM email signing [RFC6376]. In this mechanism a routing node in
a DTN sub-network vouches for the origination of a bundle by adding a a DTN sub-network attests to the origination of a bundle by adding a
BIB before forwarding it. The bundle receiver then need not trust BIB before forwarding it. The bundle receiver then need not trust
the source of the bundle, but only trust this security source node. the source of the bundle, but only trust this security source node.
The receiver needs policy configuration to know which security source The receiver needs policy configuration to know which security
is permitted to vouch for which bundle sources. sources are permitted to attest for which bundle sources.
An integrity gateway SHALL validate the Source Node ID of a bundle, An integrity gateway SHALL validate the Source Node ID of a bundle,
using local-network-specific means, before adding a BIB to the using local-network-specific means, before adding a BIB to the
bundle. The exact means by which an integrity gateway validates a bundle. The exact means by which an integrity gateway validates a
bundle's source is network-specific, but could use physical-layer, bundle's source is network-specific, but could use physical-layer,
network-layer or BP-convergence-layer authentication. The bundle network-layer or BP-convergence-layer authentication. The bundle
source could also add its own BIB with a local-network-specific source could also add its own BIB with a local-network-specific
security context or local-network-specific key material (i.e. a group security context or local-network-specific key material (i.e. a group
key shared within the local network). key shared within the local network).
When an integrity gateway adds a BIB it SHALL be in accordance with When an integrity gateway adds a BIB it SHALL be in accordance with
[I-D.ietf-dtn-bpsec]. The BIB targets SHALL cover both the payload [I-D.ietf-dtn-bpsec]. The BIB targets SHALL cover both the payload
block and the primary block (either directly as a target or as block and the primary block (either directly as a target or as
additional authenticated data for the payload block signature). The additional authenticated data for the payload block signature). The
Security Source of this BIB SHALL be either the bundle source Node ID Security Source of this BIB SHALL be either the bundle source Node ID
itself or a routing node trusted by the destination node (see itself or a routing node trusted by the destination node (see
Section 7.2). Section 8.2).
5. Certificate Request Profile 5. Certificate Request Profile
The ultimate purpose of this ACME validation is to allow a CA to The ultimate purpose of this ACME validation is to allow a CA to
issue certificates following the profiles of Section 4.4.2 of issue certificates following the profiles of Section 4.4.2 of
[I-D.ietf-dtn-tcpclv4], [I-D.sipos-dtn-udpcl], and [I-D.ietf-dtn-tcpclv4], [I-D.sipos-dtn-udpcl], and
[I-D.bsipos-dtn-bpsec-cose]. These purposes are referred to here as [I-D.bsipos-dtn-bpsec-cose]. These purposes are referred to here as
bundle security certificates. bundle security certificates.
One defining aspect of bundle security certificates is the Extended One defining aspect of bundle security certificates is the Extended
skipping to change at page 17, line 24 skipping to change at page 17, line 18
In order to request encryption only bundle security certificate, the In order to request encryption only bundle security certificate, the
CSR MUST include the key usage extension with keyEncipherment or CSR MUST include the key usage extension with keyEncipherment or
keyAgreement bits set and no other bits set. keyAgreement bits set and no other bits set.
Presence of both of the above sets of key usage bits in the CSR, as Presence of both of the above sets of key usage bits in the CSR, as
well as absence of key usage extension in the CSR, signals to ACME well as absence of key usage extension in the CSR, signals to ACME
server to issue a bundle security certificate suitable for both server to issue a bundle security certificate suitable for both
signing and encryption. signing and encryption.
6. Implementation Status 6. Bundle Protocol Administrative Record Types Registry
This document updates the requirements in Section 6.1 of
[I-D.ietf-dtn-bpbis] to use an existing IANA registry and updates
that sub-registry in Section 9.3.
Instead of using the explicit list of types in Table 3 of
[I-D.ietf-dtn-bpbis], a BP Agent SHALL interpret administrative
record type code values in accordance with the IANA "Administrative
Record Types" sub-registry for entries having a "Bundle Protocol
Version" of 7. Additionally, this document clarifies the zero-value
reservation for BPv7 and makes a reservation of high-valued record
type codes for "private or experimental use" which applies only to
BPv7.
7. Implementation Status
This section is to be removed before publishing as an RFC.
[NOTE to the RFC Editor: please remove this section before [NOTE to the RFC Editor: please remove this section before
publication, as well as the reference to [RFC7942] and publication, as well as the reference to [RFC7942] and
[github-acme-dtnnodeid].] [github-dtn-demo-agent] and [github-dtn-wireshark].]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations can features. Readers are advised to note that other implementations can
exist. exist.
An example implementation of the this draft of ACME has been created An example implementation of the this draft of ACME Node ID
as a GitHub project [github-acme-dtnnodeid] and is intended to use as Validation has been created as a GitHub project
a proof-of-concept and as a possible source of interoperability [github-dtn-demo-agent] and is intended to use as a proof-of-concept
testing. This example implementation only constructs encoded bundles and as a possible source of interoperability testing.
and does not attempt to provide a full BP Agent interface.
7. Security Considerations A Wireshark dissector for of the this draft of ACME Node ID
Validation has been created as a GitHub project
[github-dtn-wireshark] and is intended to be used to inspect and
troubleshoot implementations.
8. Security Considerations
This section separates security considerations into threat categories This section separates security considerations into threat categories
based on guidance of BCP 72 [RFC3552]. based on guidance of BCP 72 [RFC3552].
7.1. Threat: Passive Leak of Validation Data 8.1. Threat: Passive Leak of Validation Data
Because this challenge mechanism is used to bootstrap security Because this challenge mechanism is used to bootstrap security
between DTN Nodes, the challenge and its response are likely to be between DTN Nodes, the challenge and its response are likely to be
transferred in plaintext. The only ACME data present on-the-wire is transferred in plaintext. The only ACME data present on-the-wire is
a random token and a cryptographic digest, so there is no sensitive a random token and a cryptographic digest, so there is no sensitive
data to be leaked within the Node ID Validation bundle exchange. data to be leaked within the Node ID Validation bundle exchange.
Because each challenge uses a separate token, there is no value in an Because each challenge uses a separate token, there is no value in an
on-path attacker seeing the tokens from past challenges and/or on-path attacker seeing the tokens from past challenges and/or
responses. responses.
It is possible for intermediate BP nodes to encapsulate-and-encrypt It is possible for intermediate BP nodes to encapsulate-and-encrypt
Challenge and/or Response Bundles while they traverse untrusted Challenge and/or Response Bundles while they traverse untrusted
networks, but that is a DTN configuration matter outside of the scope networks, but that is a DTN configuration matter outside of the scope
of this document. of this document.
7.2. Threat: BP Node Impersonation 8.2. Threat: BP Node Impersonation
As described in Section 8.1 of [RFC8555], it is possible for an As described in Section 8.1 of [RFC8555], it is possible for an
active attacker to alter data on both ACME client channel and the DTN active attacker to alter data on both ACME client channel and the DTN
validation channel. validation channel.
The primary mitigation is to delegate bundle integrity sourcing to a The primary mitigation is to delegate bundle integrity sourcing to a
trusted routing node near, in the sense of bundle routing topology, trusted routing node near, in the sense of bundle routing topology,
to the bundle source node as defined in Section 4. This is to the bundle source node as defined in Section 4. This is
functionally similar to DKIM signing of [RFC6376] and provides some functionally similar to DKIM signing of [RFC6376] and provides some
level of bundle origination. level of bundle origination.
Another way to mitigate single-path on-path attacks is to attempt Another way to mitigate single-path on-path attacks is to attempt
validation of the same Node ID via multiple bundle routing paths, as validation of the same Node ID via multiple bundle routing paths, as
recommended in Section 3. It is not a trivial task to guarantee recommended in Section 3. It is not a trivial task to guarantee
bundle routing though, so more advanced techniques such as onion bundle routing though, so more advanced techniques such as onion
routing (using bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect]) routing (using bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect])
could be employed. could be employed.
7.3. Threat: Bundle Replay 8.3. Threat: Bundle Replay
It is possible for an on-path attacker to replay both Challenge It is possible for an on-path attacker to replay both Challenge
Bundles or Response Bundles. Even in a properly-configured DTN it is Bundles or Response Bundles. Even in a properly-configured DTN it is
possible that intermediate bundle routers to use multicast forwarding possible that intermediate bundle routers to use multicast forwarding
of a unicast-destination bundle. of a unicast-destination bundle.
Ultimately, the point of the ACME bundle exchange is to derive a Key Ultimately, the point of the ACME bundle exchange is to derive a Key
Authorization and its cryptographic digest and communicate it back to Authorization and its cryptographic digest and communicate it back to
the ACME server for validation, so the uniqueness of the Key the ACME server for validation, so the uniqueness of the Key
Authorization directly determines the scope of replay validity. The Authorization directly determines the scope of replay validity. The
skipping to change at page 19, line 21 skipping to change at page 19, line 35
uniqueness of each "token-chal" to the ACME challenge ensures that uniqueness of each "token-chal" to the ACME challenge ensures that
the Key Authorization is unique to that ACME challenge. the Key Authorization is unique to that ACME challenge.
Having each bundle's primary block and payload block covered by a BIB Having each bundle's primary block and payload block covered by a BIB
from a trusted security source (see Section 4) ensures that a from a trusted security source (see Section 4) ensures that a
replayed bundle cannot be altered in the blocks used by ACME. All replayed bundle cannot be altered in the blocks used by ACME. All
together, these properties mean that there is no degraded security together, these properties mean that there is no degraded security
caused by replay of either a Challenge Bundle or a Response Bundle caused by replay of either a Challenge Bundle or a Response Bundle
even in the case where the primary or payload block is not covered by even in the case where the primary or payload block is not covered by
a BIB. The worst that can come of bundle replay is the waste of a BIB. The worst that can come of bundle replay is the waste of
network resources as described in Section 7.4. network resources as described in Section 8.4.
7.4. Threat: Denial of Service 8.4. Threat: Denial of Service
The behaviors described in this section all amount to a potential The behaviors described in this section all amount to a potential
denial-of-service to a BP agent. denial-of-service to a BP agent.
A malicious entity can continually send Challenge Bundles to a BP A malicious entity can continually send Challenge Bundles to a BP
agent. The victim BP agent can ignore Challenge Bundles which do not agent. The victim BP agent can ignore Challenge Bundles which do not
conform to the specific time interval and challenge token for which conform to the specific time interval and challenge token for which
the ACME client has informed the BP agent that challenges are the ACME client has informed the BP agent that challenges are
expected. The victim BP agent can require all Challenge Bundles to expected. The victim BP agent can require all Challenge Bundles to
be BIB-signed to ensure authenticity of the challenge. be BIB-signed to ensure authenticity of the challenge.
skipping to change at page 19, line 45 skipping to change at page 20, line 10
A malicious entity can continually send Response Bundles to a BP A malicious entity can continually send Response Bundles to a BP
agent. The victim BP agent can ignore Response Bundles which do not agent. The victim BP agent can ignore Response Bundles which do not
conform to the specific time interval or Source Node ID or challenge conform to the specific time interval or Source Node ID or challenge
token for an active Node ID validation. token for an active Node ID validation.
Similar to other validation methods, an ACME server validating a DTN Similar to other validation methods, an ACME server validating a DTN
Node ID could be used as a denial of service amplifier. For this Node ID could be used as a denial of service amplifier. For this
reason any ACME server can rate-limit validation activities for reason any ACME server can rate-limit validation activities for
individual clients and individual certificate requests. individual clients and individual certificate requests.
8. IANA Considerations 9. IANA Considerations
This specification adds to the ACME registry and BP registry for this This specification adds to the ACME registry and BP registry for this
behavior. behavior.
8.1. ACME Identifier Type 9.1. ACME Identifier Types
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry [IANA-ACME], the following entry has been added to Protocol" registry [IANA-ACME], the following entry has been added to
the "ACME Identifier Types" sub-registry. the "ACME Identifier Types" sub-registry.
+=======+==================================+ +=======+==================================+
| Label | Reference | | Label | Reference |
+=======+==================================+ +=======+==================================+
| uri | This specification and [RFC3986] | | uri | This specification and [RFC3986] |
+-------+----------------------------------+ +-------+----------------------------------+
Table 1 Table 1
8.2. ACME Validation Method 9.2. ACME Validation Methods
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry [IANA-ACME], the following entry has been added to Protocol" registry [IANA-ACME], the following entry has been added to
the "ACME Validation Methods" sub-registry. the "ACME Validation Methods" sub-registry.
+===============+=================+======+====================+ +===============+=================+======+====================+
| Label | Identifier Type | ACME | Reference | | Label | Identifier Type | ACME | Reference |
+===============+=================+======+====================+ +===============+=================+======+====================+
| dtn-nodeid-01 | uri | Y | This specification | | dtn-nodeid-01 | uri | Y | This specification |
+---------------+-----------------+------+--------------------+ +---------------+-----------------+------+--------------------+
Table 2 Table 2
8.3. BP Bundle Administrative Record Types 9.3. Bundle Administrative Record Types
Within the "Bundle Protocol" registry [IANA-BP], the following entry Within the "Bundle Protocol" registry [IANA-BP], the "Bundle
has been added to the "Bundle Administrative Record Types" sub- Administrative Record Types" sub-registry has been updated to include
registry. [NOTE to the RFC Editor: For RFC5050 compatibility this a leftmost "Bundle Protocol Version" column. The existing sub-
value needs to be no larger than 15, but such compatibility is not registry entries have been updated to have BP versions as in the
needed. BPbis has no upper limit on this code point value.] following table.
+=========================+=======+==============+===============+ +=================+=======+===============+======================+
| Bundle Protocol Version | Value | Description | Reference | | Bundle Protocol | Value | Description | Reference |
+=========================+=======+==============+===============+ | Version | | | |
| 7 | TBD | ACME Node ID | This | +=================+=======+===============+======================+
| | | Validation | specification | | 6,7 | 0 | Reserved | [RFC7116] |
+-------------------------+-------+--------------+---------------+ +-----------------+-------+---------------+----------------------+
| 6,7 | 1 | Bundle status | [RFC5050] |
| | | report | [I-D.ietf-dtn-bpbis] |
+-----------------+-------+---------------+----------------------+
| 6 | 2 | Custody | [RFC5050] |
| | | signal | |
+-----------------+-------+---------------+----------------------+
| 6,7 | 3-15 | Unassigned | |
+-----------------+-------+---------------+----------------------+
Table 3 Table 3
9. Acknowledgments Within the "Bundle Protocol" registry [IANA-BP], the following
entries have been added to the "Bundle Administrative Record Types"
sub-registry. [NOTE to the RFC Editor: For RFC5050 compatibility the
TBD value needs to be no larger than 15, but such compatibility is
not needed. For BPbis the TBD value needs to be no larger than
65535.]
+=================+==========+======================+===============+
| Bundle Protocol | Value | Description | Reference |
| Version | | | |
+=================+==========+======================+===============+
| 7 | TBD | ACME Node ID | This |
| | | Validation | specification |
+-----------------+----------+----------------------+---------------+
| 7 | 16-65535 | Unassigned | |
+-----------------+----------+----------------------+---------------+
| 7 | >= 65536 | Reserved for | This |
| | | Private or | specification |
| | | Experimental Use | |
+-----------------+----------+----------------------+---------------+
Table 4
10. Acknowledgments
This specification is based on DTN use cases related to PKIX This specification is based on DTN use cases related to PKIX
certificate issuance. certificate issuance.
The workflow and terminology of this validation method was originally The workflow and terminology of this validation method was originally
copied from the work of Alexey Melnikov in [RFC8823]. copied from the work of Alexey Melnikov in [RFC8823].
10. References 11. References
10.1. Normative References 11.1. Normative References
[FIPS180-4] [FIPS180-4]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, August 2015, Hash Standard (SHS)", FIPS PUB 180-4, August 2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/ <https://csrc.nist.gov/publications/detail/fips/180/4/
final>. final>.
[IANA-ACME] [IANA-ACME]
IANA, "Automated Certificate Management Environment (ACME) IANA, "Automated Certificate Management Environment (ACME)
Protocol", <https://www.iana.org/assignments/acme/>. Protocol", <https://www.iana.org/assignments/acme/>.
skipping to change at page 23, line 11 skipping to change at page 23, line 48
Protocol Version 7", Work in Progress, Internet-Draft, Protocol Version 7", Work in Progress, Internet-Draft,
draft-ietf-dtn-bpbis-31, 25 January 2021, draft-ietf-dtn-bpbis-31, 25 January 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-bpbis-31>. <https://tools.ietf.org/html/draft-ietf-dtn-bpbis-31>.
[I-D.ietf-dtn-bpsec] [I-D.ietf-dtn-bpsec]
III, E. J. B. and K. McKeever, "Bundle Protocol Security III, E. J. B. and K. McKeever, "Bundle Protocol Security
Specification", Work in Progress, Internet-Draft, draft- Specification", Work in Progress, Internet-Draft, draft-
ietf-dtn-bpsec-27, 16 February 2021, ietf-dtn-bpsec-27, 16 February 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27>. <https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27>.
10.2. Informative References 11.2. Informative References
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/info/rfc5050>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission
Protocol (LTP), Compressed Bundle Header Encoding (CBHE),
and Bundle Protocol IANA Registries", RFC 7116,
DOI 10.17487/RFC7116, February 2014,
<https://www.rfc-editor.org/info/rfc7116>.
[RFC8823] Melnikov, A., "Extensions to Automatic Certificate [RFC8823] Melnikov, A., "Extensions to Automatic Certificate
Management Environment for End-User S/MIME Certificates", Management Environment for End-User S/MIME Certificates",
RFC 8823, DOI 10.17487/RFC8823, April 2021, RFC 8823, DOI 10.17487/RFC8823, April 2021,
<https://www.rfc-editor.org/info/rfc8823>. <https://www.rfc-editor.org/info/rfc8823>.
[I-D.ietf-dtn-bibect] [I-D.ietf-dtn-bibect]
Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in
Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18
February 2020, February 2020,
<https://tools.ietf.org/html/draft-ietf-dtn-bibect-03>. <https://tools.ietf.org/html/draft-ietf-dtn-bibect-03>.
skipping to change at page 23, line 49 skipping to change at page 24, line 47
sipos-dtn-udpcl-01, 26 March 2021, sipos-dtn-udpcl-01, 26 March 2021,
<https://tools.ietf.org/html/draft-sipos-dtn-udpcl-01>. <https://tools.ietf.org/html/draft-sipos-dtn-udpcl-01>.
[I-D.bsipos-dtn-bpsec-cose] [I-D.bsipos-dtn-bpsec-cose]
Sipos, B., "DTN Bundle Protocol Security COSE Security Sipos, B., "DTN Bundle Protocol Security COSE Security
Context", Work in Progress, Internet-Draft, draft-bsipos- Context", Work in Progress, Internet-Draft, draft-bsipos-
dtn-bpsec-cose-05, 16 March 2021, dtn-bpsec-cose-05, 16 March 2021,
<https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose- <https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose-
05>. 05>.
[github-acme-dtnnodeid] [github-dtn-demo-agent]
Sipos, B., "ACME Node ID Example Implementation", Sipos, B., "Python implementation of basic BPv7-related
<https://github.com/BSipos-RKF/acme-dtnnodeid/>. protocols",
<https://github.com/BSipos-RKF/dtn-demo-agent/>.
[github-dtn-wireshark]
Sipos, B., "Wireshark Dissectors for BPv7-related
Protocols",
<https://github.com/BSipos-RKF/dtn-wireshark/>.
Appendix A. Administrative Record Types CDDL Appendix A. Administrative Record Types CDDL
[NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the [NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the
"ACME Node ID Validation" administrative record type code.] "ACME Node ID Validation" administrative record type code.]
The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles
is: is:
; All ACME records have the same structure ; All ACME records have the same structure
 End of changes. 36 change blocks. 
76 lines changed or deleted 151 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/