draft-ietf-acme-dtnnodeid-07.txt   draft-ietf-acme-dtnnodeid-08.txt 
Automated Certificate Management Environment B. Sipos Automated Certificate Management Environment B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Intended status: Experimental 14 November 2021 Intended status: Experimental 10 January 2022
Expires: 18 May 2022 Expires: 14 July 2022
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-07 draft-ietf-acme-dtnnodeid-08
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 otherName with a name form of Alternative Name (SAN) of type otherName with a name form of
BundleEID and as an ACME Identifier type "bundleEID". BundleEID and as an ACME Identifier type "bundleEID".
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 18 May 2022. This Internet-Draft will expire on 14 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 5 1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 4
1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Bundle Endpoint ID ACME Identifier . . . . . . . . . . . . . 7 2. Bundle Endpoint ID ACME Identifier . . . . . . . . . . . . . 8
3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 8 2.1. Subsets of Endpoint ID . . . . . . . . . . . . . . . . . 8
3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 11 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 9
3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 12 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 12
3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 13
3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 13 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 13
3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 14 3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 15
3.4. ACME Node ID Validation Response Bundles . . . . . . . . 14 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 15
3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 16 3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 16
3.5. Multi-Perspective Validation . . . . . . . . . . . . . . 16 3.5. Multi-Perspective Validation . . . . . . . . . . . . . . 17
4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 17 4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 17
5. Certificate Request Profile . . . . . . . . . . . . . . . . . 17 5. Certificate Request Profile . . . . . . . . . . . . . . . . . 18
5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 18 5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 18
5.2. Generating Encryption-only or Signing-only Bundle Security 5.2. Generating Encryption-only or Signing-only Bundle Security
Certificates . . . . . . . . . . . . . . . . . . . . . . 18 Certificates . . . . . . . . . . . . . . . . . . . . . . 19
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7.1. Threat: Passive Leak of Validation Data . . . . . . . . . 19 7.1. Threat: Passive Leak of Validation Data . . . . . . . . . 20
7.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 20 7.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 20
7.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 20 7.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 21
7.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 20 7.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 21
7.5. Inherited Security Considerations . . . . . . . . . . . . 21 7.5. Inherited Security Considerations . . . . . . . . . . . . 22
7.6. Out-of-Scope BP Agent Communication . . . . . . . . . . . 21 7.6. Out-of-Scope BP Agent Communication . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 22 8.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 22
8.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 22 8.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 23
8.3. Bundle Administrative Record Types . . . . . . . . . . . 22 8.3. Bundle Administrative Record Types . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Administrative Record Types CDDL . . . . . . . . . . 27 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 27
Appendix B. Example Authorization . . . . . . . . . . . . . . . 27 Appendix B. Example Authorization . . . . . . . . . . . . . . . 28
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 27 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 28
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 28 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
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 7, line 20 skipping to change at page 6, line 43
start = acme-record / bundle / tstr start = acme-record / bundle / tstr
1.4. Terminology 1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Because this document combines two otherwise unrelated contexts, ACME
and DTN, when a protocol term applies to one of those areas and is
used in the other its name is prefixed with either "ACME" or "DTN"
respectively. Thus within the ACME context the term is "DTN Node ID"
while in the DTN context the name is just "Node ID".
In this document, several terms are shortened for the sake of In this document, several terms are shortened for the sake of
terseness. These terms are: terseness. These terms are:
Challenge Request: This is a shortened form of the full "DTN Node ID Challenge Request: This is a shortened form of the full "DTN Node ID
Challenge Request Object". It is a JSON object created by the Challenge Request Object". It is a JSON object created by the
ACME server for challenge type "dtn-nodeid-01". ACME server for challenge type "dtn-nodeid-01".
Challenge Response: This is a shortened form of the full "DTN Node Challenge Response: This is a shortened form of the full "DTN Node
ID Challenge Response Object". It is a JSON object created by the ID Challenge Response Object". It is a JSON object created by the
ACME client to authorize a challenge type "dtn-nodeid-01". ACME client to authorize a challenge type "dtn-nodeid-01".
Challenge Bundle: This is a shortened form of the full "ACME Node ID Challenge Bundle: This is a shortened form of the full "ACME Node ID
Validation Challenge Bundle". It is a Bundle created by the BP Validation Challenge Bundle". It is a Bundle created by the BP
agent managed by the ACME server to challenge a Node ID claim. agent managed by the ACME server to challenge a Node ID claim.
Response Bundle: This is a shortened form of the full "ACME Node ID Response Bundle: This is a shortened form of the full "ACME Node ID
Validation Response Bundle". It is a Bundle created by the BP Validation Response Bundle". It is a Bundle created by the BP
agent managed by the ACME client to validate a Node ID claim. agent managed by the ACME client to validate a Node ID claim.
Because this is an ACME document, the following DTN Bundle Protocol
terms are defined here to clarify how they are used by this ACME
identifier type and validation mechanism.
Endpoint ID: An Endpoint ID is an identifier for the ultimate
destination of a bundle, independent of any intermediate
forwarding needed to reach that destination. An endpoint can be a
singleton (unicast) or not (anycast or multicast) so an Endpoint
ID can also represent a single entity or a set of entities. This
is formally defined in Section 4.2.5.1 of [I-D.ietf-dtn-bpbis].
Node ID: A Node ID is a (not guaranteed unique) identifier for a
specific node in a network in the form of a singleton Endpoint ID.
A single node can have any number of Node IDs but a typical (and
expected) form of Node ID is the Administrative Endpoint ID
(described below). This is formally defined in Section 4.2.5.2 of
[I-D.ietf-dtn-bpbis].
Administrative Endpoint ID: An Administrative Endpoint ID is unique
for a node within a specific URI scheme. Although any Node ID can
be a valid bundle Source and Destination, the Administrative
Endpoint ID is a minimum required Node ID for any node operating
in a particular URI scheme. For the "dtn" scheme this is the
empty demux part and for the "ipn" scheme this is the service
number zero. These is formally defined under Section 4.2.5.1 of
[I-D.ietf-dtn-bpbis].
2. Bundle Endpoint ID ACME Identifier 2. Bundle Endpoint ID ACME Identifier
This specification is the first to make use of an Bundle Endpoint ID This specification is the first to make use of an Bundle Endpoint ID
to identify a claim for a certificate request in ACME. In this to identify a claim for a certificate request in ACME. In this
document, the only purpose for which an Bundle Endpoint ID ACME document, the only purpose for which an Bundle Endpoint ID ACME
identifier is validated is as a DTN Node ID (see Section 3), but identifier is validated is as a DTN Node ID (see Section 3), but
other specifications can define challenge types for other Endpoint ID other specifications can define challenge types for other Endpoint ID
uses. uses.
Identifiers of type "bundleEID" in certificate requests MUST appear Identifiers of type "bundleEID" in certificate requests SHALL appear
in an extensionRequest attribute [RFC2985] containing a in an extensionRequest attribute [RFC2985] containing a
subjectAltName extension of type otherName with a name form of subjectAltName extension of type otherName with a name form of
BundleEID, identified by id-on-bundleEID of [IANA-SMI], consistent BundleEID, identified by id-on-bundleEID of [IANA-SMI], consistent
with the requirements of Section 4.4.2.1 of [I-D.ietf-dtn-tcpclv4]. with the requirements of Section 4.4.2.1 of [I-D.ietf-dtn-tcpclv4].
Because the BundleEID is encoded as an IA5String it SHALL be treated Because the BundleEID is encoded as an IA5String it SHALL be treated
as being in the percent-encoded form of Section 2.1 of [RFC3986]. as being in the percent-encoded form of Section 2.1 of [RFC3986].
Any "bundleEID" identifier which fails to properly percent-decode Any "bundleEID" identifier which fails to properly percent-decode
SHALL be rejected with an ACME error type of "malformed". SHALL be rejected with an ACME error type of "malformed".
The ACME server SHALL decode and normalize (based on scheme-specific The ACME server SHALL decode and normalize (based on scheme-specific
syntax) all received identifiers of type "bundleEID". Any syntax) all received identifiers of type "bundleEID". Any
"bundleEID" identifier request which uses a scheme not handled by the "bundleEID" identifier request which uses a scheme not handled by the
ACME server or for which the EID does not match the scheme-specific ACME server or for which the EID does not match the scheme-specific
syntax SHALL be rejected with an ACME error type of syntax SHALL be rejected with an ACME error type of
skipping to change at page 8, line 32 skipping to change at page 8, line 46
authorized by the ACME client. authorized by the ACME client.
An identifier for the Node ID of "dtn://example/" would be formatted An identifier for the Node ID of "dtn://example/" would be formatted
as: as:
{ {
"type": "bundleEID", "type": "bundleEID",
"value": "dtn://example/" "value": "dtn://example/"
} }
2.1. Subsets of Endpoint ID
While the PKIX other name form of BundleEID can hold any Endpoint ID
value, the certificate profile used by [I-D.ietf-dtn-tcpclv4] and
supported by this ACME validation method in Section 3 requires that
the value hold a Node ID.
In addition to the narrowing of that certificate profile, this
validation method requires that the client's BP agent responds to
administrative records sent to the Node ID being validated. This
typically is limited to an Administrative Endpoint ID, but there is
no prohibition on the administrative element of a BP node from
receiving administrative records for, and sending records from, other
Node IDs in order to support this validation method.
Neither that certificate profile nor this validation method support
operating on non-singleton Endpoint IDs, but other validation methods
could be defined to do so in order to support other certificate
profiles.
3. DTN Node ID Validation 3. DTN Node ID Validation
The DTN Node ID validation method proves control over a Node ID by The DTN Node ID validation method proves control over a Node ID by
requiring the ACME client to configure a BP agent to respond to requiring the ACME client to configure a BP agent to respond to
specific Challenge Bundles sent from the ACME server. The ACME specific Challenge Bundles sent from the ACME server. The ACME
server validates control of the Node ID by verifying that received server validates control of the Node ID by verifying that received
Response Bundles correspond with the BP Node and client account key Response Bundles correspond with the BP Node and client account key
being validated. being validated.
Similar to the ACME use case for validating email address ownership Similar to the ACME use case for validating email address ownership
[RFC8823], this challenge splits the token into several parts, each [RFC8823], this challenge splits the token into several parts, each
being transported by a different channel, and the Key Authorization being transported by a different channel, and the Key Authorization
result requires combining all parts of the token. The token parts result requires combining all parts of the token. A separate
are: challenge identifier is used as a filter by BP agents similarly to
the challenge "from" email address of [RFC8823].
token-chal: This token is unique to, and identifies, each ACME The token parts are:
authorization. It is contained in the Challenge Object of
Section 3.1 as well as the Challenge Bundle of Section 3.3 and token-chal: This token is unique to each ACME authorization. It is
Response Bundle of Section 3.4. Each authorization can consist of contained in the Challenge Object of Section 3.1. Each
multiple Challenge Bundles (e.g. taking different routes), but authorization can consist of multiple Challenge Bundles (e.g.
they all share the same token-chal value. This ensures that the taking different routes), but they all share the same token-chal
Key Authorization is bound to the specific ACME challenge (and value. This ensures that the Key Authorization is bound to the
parent ACME authorization) and also allows the ACME client's BP specific ACME challenge (and parent ACME authorization). This
agent to filter-in only valid Challenge Bundles. This token is token does not appear on the BP channel so that any eavesdropper
also accessible to DTN on-path eavesdroppers. knowing the client's account key thumbprint (e.g. from some other
validation method) is not able to impersonate the client.
token-bundle: This token is unique to each Challenge Bundle sent by token-bundle: This token is unique to each Challenge Bundle sent by
the ACME server. It is contained in the Challenge Bundle of the ACME server. It is contained in the Challenge Bundle of
Section 3.3 and Response Bundle of Section 3.4. This ensures that Section 3.3 and Response Bundle of Section 3.4. This ensures that
the Key Authorization is bound to the ability to receive the the Key Authorization is bound to the ability to receive the
Challenge Bundle and not just have access to the ACME Challenge Challenge Bundle and not just have access to the ACME Challenge
Object. This token is also accessible to DTN on-path Object. This token is also accessible to DTN on-path
eavesdroppers. eavesdroppers.
For each ACME server, the pair of token-chal and token-bundle values
is the unique correlator between Challenge and Response bundles.
Because multiple Challenge Bundles can be sent to validate the same Because multiple Challenge Bundles can be sent to validate the same
Node ID, the token-bundle in the response is needed to correlate with Node ID, the token-bundle in the response is needed to correlate with
the expected Key Authorization digest. the expected Key Authorization digest.
The DTN Node ID Challenge SHALL only be allowed for an EID usable as The DTN Node ID Challenge SHALL only be allowed for an EID usable as
a DTN Node ID, which [I-D.ietf-dtn-bpbis]. When an ACME server a DTN Node ID, which is defined per-scheme in Section 4.2.5.1 of
supports Node ID validation, the ACME server SHALL define a challenge [I-D.ietf-dtn-bpbis]. When an ACME server supports Node ID
object in accordance with Section 3.1. Once this challenge object is validation, the ACME server SHALL define a challenge object in
defined, the ACME client may begin the validation. accordance with Section 3.1. Once this challenge object is defined,
the ACME client may begin the validation.
To initiate a Node ID validation, the ACME client performs the To initiate a Node ID validation, the ACME client performs the
following steps: following steps:
1. The ACME client POSTs a newOrder or newAuthz request including 1. The ACME client POSTs a newOrder or newAuthz request including
the identifier of type "bundleEID" for the desired Node ID. From the identifier of type "bundleEID" for the desired Node ID. From
either of these entry points an authorization for the "bundleEID" either of these entry points an authorization for the "bundleEID"
type is indicated by the ACME server. See Section 7.4 of type is indicated by the ACME server. See Section 7.4 of
[RFC8555] for more details. [RFC8555] for more details.
2. The ACME client obtains the challenge source Node ID and token- 2. The ACME client obtains the id-chal and token-chal from the
chal from the challenge object in accordance with Section 3.1. challenge object in accordance with Section 3.1.
3. The ACME client indicates to the administrative element of its BP 3. The ACME client indicates to the administrative element of its BP
agent the source Node ID and challenge token-chal which is agent the id-chal which is authorized for use along with the
authorized for use and the associated client account key associated token-chal and client account key thumbprint. The
thumbprint. The ACME client SHALL wait, if necessary, until the ACME client SHALL wait, if necessary, until the agent is
agent is configured before proceeding to the next step. configured before proceeding to the next step.
4. The ACME client POSTs a challenge response to the challenge URL 4. The ACME client POSTs a challenge response to the challenge URL
on the ACME server accordance with Section 7.5.1 of [RFC8555]. on the ACME server accordance with Section 7.5.1 of [RFC8555].
The payload object is constructed in accordance with Section 3.2. The payload object is constructed in accordance with Section 3.2.
5. The administrative element waits for a Challenge Bundle to be 5. The administrative element waits for a Challenge Bundle to be
received with the authorized ACME parameters, including its received with the authorized ACME parameters, including its id-
token-bundle payload, in accordance with Section 3.3. chal payload, in accordance with Section 3.3.
6. The administrative element concatenates token-bundle with token- 6. The administrative element concatenates token-bundle with token-
chal (each as base64url-encoded text strings) and computes the chal (each as base64url-encoded text strings) and computes the
Key Authorization in accordance with Section 8.1 of [RFC8555] Key Authorization in accordance with Section 8.1 of [RFC8555]
using the full token and client account key thumbprint. using the full token and client account key thumbprint.
7. The administrative element computes the SHA-256 digest of the Key 7. The administrative element computes the SHA-256 digest of the Key
Authorization result and generates a Response Bundle to send back Authorization result and generates a Response Bundle to send back
to the ACME server in accordance with Section 3.4. to the ACME server in accordance with Section 3.4.
8. The ACME client waits for the authorization to be finalized on 8. The ACME client waits for the authorization to be finalized on
the ACME server in accordance with Section 7.5.1 of [RFC8555]. the ACME server in accordance with Section 7.5.1 of [RFC8555].
9. Once the challenge is completed (successfully or not), the ACME 9. Once the challenge is completed (successfully or not), the ACME
client indicates to the BP agent that the validation source and client indicates to the BP agent that the id-chal is no longer
token-chal is no longer usable. If the authorization fails, the usable. If the authorization fails, the ACME client MAY retry
ACME client MAY retry the challenge from Step 3. the challenge from Step 3.
The ACME server verifies the client's control over a Node ID by The ACME server verifies the client's control over a Node ID by
performing the following steps: performing the following steps:
1. The ACME server receives a newOrder or newAuthz request including 1. The ACME server receives a newOrder or newAuthz request including
the identifier of type "bundleEID", where the URI value is a Node the identifier of type "bundleEID", where the URI value is a Node
ID. ID.
2. The ACME server generates an authorization for the Node ID with 2. The ACME server generates an authorization for the Node ID with
challenge type "dtn-nodeid-01" in accordance with Section 3.1. challenge type "dtn-nodeid-01" in accordance with Section 3.1.
skipping to change at page 11, line 14 skipping to change at page 11, line 45
6. Once received and decoded, the ACME server checks the contents of 6. Once received and decoded, the ACME server checks the contents of
each Response Bundle in accordance with Section 3.4.1. After all each Response Bundle in accordance with Section 3.4.1. After all
Challenge Bundles have either been responded to or timed-out, the Challenge Bundles have either been responded to or timed-out, the
ACME server policy (see Section 3.5) determines whether the ACME server policy (see Section 3.5) determines whether the
validation is successful. If validation is not successful, a validation is successful. If validation is not successful, a
client may retry the challenge which starts in Step 3. client may retry the challenge which starts in Step 3.
When responding to a Challenge Bundle, a BP agent SHALL send a single When responding to a Challenge Bundle, a BP agent SHALL send a single
Response Bundle in accordance with Section 3.4. A BP agent SHALL Response Bundle in accordance with Section 3.4. A BP agent SHALL
respond to ACME challenges only within the interval of time, only for respond to ACME challenges only within the interval of time and only
the Node ID, and only for the token-chal indicated by the ACME for the id-chal indicated by the ACME client. A BP agent SHALL
client. A BP agent SHALL respond to multiple Challenge Bundles with respond to multiple Challenge Bundles with the same ACME parameters
the same ACME parameters but different bundle identities (source Node but different bundle identities (source Node ID and timestamp); these
ID and timestamp); these correspond with the ACME server validating correspond with the ACME server validating via multiple routing
via multiple routing paths. paths.
3.1. DTN Node ID Challenge Request Object 3.1. DTN Node ID Challenge Request Object
The DTN Node ID Challenge request object is defined by the ACME The DTN Node ID Challenge request object is defined by the ACME
server when it supports validating Node IDs. server when it supports validating Node IDs.
The DTN Node ID Challenge request object has the following content: The DTN Node ID Challenge request object has the following content:
type (required, string): The string "dtn-nodeid-01". type (required, string): The string "dtn-nodeid-01".
source (required, array of string): An unordered list of possible id-chal (required, string): This is a random value associated with a
source Node ID of bundles originating at the BP agent(s) of the challenge which allows a client to filter valid Challenge Bundles.
ACME server. See Section 3.5 for a discussion of multi- The same value is used for all Challenge Bundles associated with
perspective validation using multiple sources. The array SHALL be an ACME challenge, including multi-perspective validation using
non-empty. The array MAY contain Node IDs which are not actually multiple sources as described in Section 3.5. This value SHALL
used as a challenge bundle source. have at least 128 bits of entropy. It SHALL NOT contain any
characters outside the base64url alphabet as described in
Section 5 of [RFC4648]. Trailing '=' padding characters SHALL be
stripped. See [RFC4086] for additional information on randomness
requirements.
token-chal (required, string): A random value that uniquely token-chal (required, string): This is a random value, used as part
identifies the challenge. This value MUST have at least 128 bits of the Key Authorization algorithm, which is communicated to the
of entropy. It MUST NOT contain any characters outside the ACME client only over the ACME channel. This value SHALL have at
base64url alphabet as described in Section 5 of [RFC4648]. least 128 bits of entropy. It SHALL NOT contain any characters
Trailing '=' padding characters MUST be stripped. See [RFC4086] outside the base64url alphabet as described in Section 5 of
for additional information on randomness requirements. [RFC4648]. Trailing '=' padding characters SHALL be stripped.
See [RFC4086] for additional information on randomness
requirements.
{ {
"type": "dtn-nodeid-01", "type": "dtn-nodeid-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4", "url": "https://example.com/acme/chall/prV_B7yEyA4",
"source": ["dtn://acme-server/"], "id-chal": "dDtaviYTPUWFS3NK37YWfQ",
"token-chal": "tPUZNY4ONIk6LxErRFEjVw" "token-chal": "tPUZNY4ONIk6LxErRFEjVw"
} }
The token-chal value included in this object is fixed for the entire
The token-chal value included in this object applies to the entire
challenge, and may correspond with multiple separate token-bundle challenge, and may correspond with multiple separate token-bundle
values when multiple Challenge Bundles are sent for a single values when multiple Challenge Bundles are sent for a single
validation. validation.
3.2. DTN Node ID Challenge Response Object 3.2. DTN Node ID Challenge Response Object
The DTN Node ID Challenge response object is defined by the ACME The DTN Node ID Challenge response object is defined by the ACME
client when it authorizes validation of a Node ID. Because a DTN has client when it authorizes validation of a Node ID. Because a DTN has
the potential for significantly longer delays than a non-DTN network, the potential for significantly longer delays than a non-DTN network,
the ACME client is able to inform the ACME server if a particular the ACME client is able to inform the ACME server if a particular
skipping to change at page 13, line 16 skipping to change at page 14, line 7
Each ACME Node ID Validation Challenge Bundle SHALL be structured and Each ACME Node ID Validation Challenge Bundle SHALL be structured and
encoded in accordance with [I-D.ietf-dtn-bpbis]. 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
primary block flags SHALL indicate that user application primary block flags SHALL indicate that user application
acknowledgement is requested; this flag distinguishes the acknowledgement is requested; this flag distinguishes the
Challenge Bundle from the Response Bundle. The primary block Challenge Bundle from the Response Bundle.
flags MAY indicate that status reports are requested; such status
can be helpful to troubleshoot routing issues.
Destination EID: The Destination EID SHALL be the ACME-server- Destination EID: The Destination EID SHALL be the ACME-server-
normalized Node ID being validated. normalized Node ID being validated.
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 a
BP agent of the ACME server performing the challenge. The BP agent of the ACME server performing the challenge.
challenge bundle source SHALL be present in the "source" array of
the challenge object (see Section 3.1)
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 (of Section 3.2) for which SHALL indicate the response interval (of Section 3.2) for which
ACME server will accept responses to this challenge. ACME server will 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 8.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 a id-chal, copied from the challenge object, 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, represented as a CBOR byte string. The token- token-bundle, represented as a CBOR byte string. The token-
bundle is a random value that uniquely identifies the challenge bundle is a random value that uniquely identifies the challenge
bundle. This value MUST have at least 128 bits of entropy. bundle. This value SHALL have at least 128 bits of entropy.
See [RFC4086] for additional information on randomness See [RFC4086] for additional information on randomness
requirements. requirements.
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 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 7.1).
skipping to change at page 14, line 23 skipping to change at page 15, line 13
(see Section 7.1). (see Section 7.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. The allowed interval starts at the Creation for the challenge. The allowed interval starts at the Creation
Timestamp and extends for the Lifetime of the Challenge Bundle. Timestamp and extends for the Lifetime of the Challenge Bundle.
* The Challenge Bundle Source Node ID is identical to the Node ID
indicated in the ACME challenge object. The comparison of Node
IDs SHALL use the comparison logic of the NODE-ID from
Section 4.4.1 of [I-D.ietf-dtn-tcpclv4].
* The Challenge Bundle contains a BIB which covers at least the * The Challenge Bundle contains a BIB which covers at least the
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 (i.e. is trusted and passes security-context-specific validation (i.e.
MAC or signature verification). MAC or signature verification).
* The challenge payload contains the token-chal as indicated in the * The challenge payload contains the id-chal as indicated in the
ACME challenge object. The challenge payload contains a token- ACME challenge object. The challenge payload contains a token-
bundle meeting the definition in Section 3.3. bundle meeting the definition in Section 3.3.
Any of the failures above SHALL cause the challenge bundle to be Any of the failures above SHALL cause the challenge bundle to be
deleted and otherwise ignored by the BP agent. The BP agent MAY send deleted and otherwise ignored by the BP agent.
status reports about the deletion if allowed by security policy.
3.4. ACME Node ID Validation Response Bundles 3.4. ACME Node ID Validation Response Bundles
Each ACME Node ID Validation Response Bundle SHALL be structured and Each ACME Node ID Validation Response Bundle SHALL be structured and
encoded in accordance with [I-D.ietf-dtn-bpbis]. encoded in accordance with [I-D.ietf-dtn-bpbis].
Each Response Bundle has parameters as listed here: Each Response 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
primary block flags SHALL NOT indicate that user application primary block flags SHALL NOT indicate that user application
acknowledgement is requested; this flag distinguishes the Response acknowledgement is requested; this flag distinguishes the Response
Bundle from the Challenge Bundle. The primary block flags MAY Bundle from the Challenge Bundle.
indicate that status reports are requested; such status can be
helpful to troubleshoot routing issues.
Destination EID: The Destination EID SHALL be identical to the Destination EID: The Destination EID SHALL be identical to the
Source Node ID of the Challenge Bundle to which this response Source Node ID of the Challenge Bundle to which this response
corresponds. corresponds.
Source Node ID: The Source Node ID SHALL be identical to the Source Node ID: The Source Node ID SHALL be identical to 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
skipping to change at page 15, line 28 skipping to change at page 16, line 9
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 8.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 id-chal, copied from the Request Bundle, represented as a CBOR
CBOR byte string. 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 a token-bundle, copied from the Request Bundle, represented as a
CBOR byte string. CBOR byte string.
* One pair SHALL consist of key 3 with value of the SHA-256 * One pair SHALL consist of key 3 with value of the SHA-256
digest [FIPS180-4] of the ACME Key Authorization in accordance digest [FIPS180-4] of the ACME Key Authorization in accordance
with Section 8.1 of [RFC8555], represented as a CBOR byte with Section 8.1 of [RFC8555], represented as a CBOR byte
string. string.
skipping to change at page 16, line 25 skipping to change at page 17, line 5
* 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
comparison logic of the NODE-ID from Section 4.4.1 of comparison logic of the NODE-ID from Section 4.4.1 of
[I-D.ietf-dtn-tcpclv4]. [I-D.ietf-dtn-tcpclv4].
* The Response Bundle contains a BIB which covers at least the * The Response Bundle contains a BIB which covers at least the
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 same token-chal and token-bundle * The response payload contains the same id-chal and token-bundle as
as sent in the Challenge Bundle (this is also how the two bundles sent in the Challenge Bundle (this is also how the two bundles are
are correlated). The response payload contains the expected Key correlated). The response payload contains the expected Key
Authorization digest computed by the ACME server. Authorization digest computed by the ACME server.
Any of the failures above SHALL cause that single-perspective Any of the failures above SHALL cause that single-perspective
validation to fail. Any of the failures above SHOULD be validation to fail. Any of the failures above SHOULD be
distinguished as subproblems to the ACME client. The lack of a distinguished as subproblems to the ACME client. The lack of a
response within the expected response interval, as defined in response within the expected response interval, as defined in
Section 3.2, SHALL also be treated as a validation failure. Section 3.2, SHALL also be treated as a validation failure.
3.5. Multi-Perspective Validation 3.5. Multi-Perspective Validation
skipping to change at page 18, line 18 skipping to change at page 18, line 43
include an Extended Key Usage of id-kp-bundleSecurity. When a bundle include an Extended Key Usage of id-kp-bundleSecurity. When a bundle
security certificate is issued based on a validated Node ID SAN, the security certificate is issued based on a validated Node ID SAN, the
certificate SHALL include an Extended Key Usage of id-kp- certificate SHALL include an Extended Key Usage of id-kp-
bundleSecurity. bundleSecurity.
5.1. Multiple Identity Claims 5.1. Multiple Identity Claims
A single bundle security CSR MAY contain a mixed set of SAN claims, A single bundle security CSR MAY contain a mixed set of SAN claims,
including combinations of "ip", "dns", and "bundleEID" claims. There including combinations of "ip", "dns", and "bundleEID" claims. There
is no restriction on how a certificate combines these claims, but is no restriction on how a certificate combines these claims, but
each claim MUST be validated by an ACME server to issue such a each claim SHALL be validated by an ACME server to issue such a
certificate as part of an associated ACME order. This is no certificate as part of an associated ACME order. This is no
different than the existing behavior of [RFC8555] but is mentioned different than the existing behavior of [RFC8555] but is mentioned
here to make sure that CA policy handles such situations; especially here to make sure that CA policy handles such situations; especially
related to validation failure of an identifier in the presence of related to validation failure of an identifier in the presence of
multiple identifiers. The specific use case of multiple identifiers. The initial "ip" validations are defined in
[I-D.ietf-dtn-tcpclv4] allows, and for some network policies [RFC8738] and initial "dns" validations are defined in [RFC8555] and
requires, that a certificate authenticate both the DNS name of an [RFC8737]. The specific use case of [I-D.ietf-dtn-tcpclv4] allows,
entity as well as the Node ID of the entity. and for some network policies requires, that a certificate
authenticate both the DNS name of an entity as well as the Node ID of
the entity.
5.2. Generating Encryption-only or Signing-only Bundle Security 5.2. Generating Encryption-only or Signing-only Bundle Security
Certificates Certificates
ACME extensions specified in this document can be used to request ACME extensions specified in this document can be used to request
encryption-only or signing-only bundle security certificates. encryption-only or signing-only bundle security certificates.
In order to request signing only bundle security certificate, the CSR In order to request signing only bundle security certificate, the CSR
MUST include the key usage extension with digitalSignature and/or SHALL include the key usage extension with digitalSignature and/or
nonRepudiation bits set and no other bits set. nonRepudiation bits set and no other bits set.
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 SHALL 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. Implementation Status
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
skipping to change at page 19, line 44 skipping to change at page 20, line 22
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 7.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 pair, there is no value
on-path attacker seeing the tokens from past challenges and/or in an 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 7.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
skipping to change at page 20, line 38 skipping to change at page 21, line 19
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
uniqueness of each token-bundle to each challenge bundle ensures that uniqueness of each token-bundle to each challenge bundle ensures that
the Key Authorization is unique to the challenge bundle. The the Key Authorization is unique to the challenge bundle. The
uniqueness of each token-chal to the ACME challenge ensures that the uniqueness of each token-chal to the ACME challenge ensures that the
Key Authorization is unique to that ACME challenge. Key Authorization is unique to that ACME challenge and not based
solely on values visible to on-path eavesdroppers.
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 7.4.
skipping to change at page 21, line 44 skipping to change at page 22, line 27
Although messaging between an ACME client or ACME server an its Although messaging between an ACME client or ACME server an its
associated BP agent are out-of-scope for this document, both of those associated BP agent are out-of-scope for this document, both of those
channels are critical to Node ID validation security. Either channel channels are critical to Node ID validation security. Either channel
can potentially leak data or provide attack vectors if not properly can potentially leak data or provide attack vectors if not properly
secured. These channels need to protect against spoofing of secured. These channels need to protect against spoofing of
messaging in both directions to avoid interruption of normal messaging in both directions to avoid interruption of normal
validation sequencing and to prevent false validations from validation sequencing and to prevent false validations from
succeeding. succeeding.
The ACME server and its BP agent exchange the outgoing token-chal, The ACME server and its BP agent exchange the outgoing id-chal,
token-bundle, and Key Authorization digest but these values do not token-bundle, and Key Authorization digest but these values do not
need to be confidential (they are also in plaintext over the BP need to be confidential (they are also in plaintext over the BP
channel). channel).
Depending on implementation details, the ACME client might transmit Depending on implementation details, the ACME client might transmit
the client account key thumbprint to its BP agent to allow computing the client account key thumbprint to its BP agent to allow computing
the Key Authorization digest on the BP agent. If an ACME client does the Key Authorization digest on the BP agent. If an ACME client does
transmit its client account key thumbprint to a BP agent, it is transmit its client account key thumbprint to a BP agent, it is
important that this data is kept confidential because it provides the important that this data is kept confidential because it provides the
binding of the client account key to the Node ID validation (as well binding of the client account key to the Node ID validation (as well
skipping to change at page 23, line 19 skipping to change at page 23, line 47
+=========================+========+==============+===============+ +=========================+========+==============+===============+
| Bundle Protocol Version | Value | Description | Reference | | Bundle Protocol Version | Value | Description | Reference |
+=========================+========+==============+===============+ +=========================+========+==============+===============+
| 7 | AR-TBD | ACME Node ID | This | | 7 | AR-TBD | ACME Node ID | This |
| | | Validation | specification | | | | Validation | specification |
+-------------------------+--------+--------------+---------------+ +-------------------------+--------+--------------+---------------+
Table 3 Table 3
9. Acknowledgments 9. References
This specification is based on DTN use cases related to PKIX
certificate issuance.
The workflow and terminology of this validation method was originally
copied from the work of Alexey Melnikov in [RFC8823].
10. References
10.1. Normative References 9.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 25, line 25 skipping to change at page 25, line 50
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn- <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpbis-31>. 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://datatracker.ietf.org/doc/html/draft-ietf-dtn- <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpsec-27>. bpsec-27>.
10.2. Informative References 9.2. Informative References
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/info/rfc5050>. 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>.
[RFC8737] Shoemaker, R.B., "Automated Certificate Management
Environment (ACME) TLS Application-Layer Protocol
Negotiation (ALPN) Challenge Extension", RFC 8737,
DOI 10.17487/RFC8737, February 2020,
<https://www.rfc-editor.org/info/rfc8737>.
[RFC8738] Shoemaker, R.B., "Automated Certificate Management
Environment (ACME) IP Identifier Validation Extension",
RFC 8738, DOI 10.17487/RFC8738, February 2020,
<https://www.rfc-editor.org/info/rfc8738>.
[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, <https://datatracker.ietf.org/doc/html/ February 2020, <https://datatracker.ietf.org/doc/html/
draft-ietf-dtn-bibect-03>. draft-ietf-dtn-bibect-03>.
skipping to change at page 26, line 37 skipping to change at page 27, line 22
[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-06, 3 June 2021, dtn-bpsec-cose-06, 3 June 2021,
<https://datatracker.ietf.org/doc/html/draft-bsipos-dtn- <https://datatracker.ietf.org/doc/html/draft-bsipos-dtn-
bpsec-cose-06>. bpsec-cose-06>.
[github-dtn-demo-agent] [github-dtn-demo-agent]
Sipos, B., "Python implementation of basic BPv7-related Sipos, B., "Python implementation of basic BPv7-related
protocols", protocols",
<https://github.com/BSipos-RKF/dtn-demo-agent/>. <https://github.com/BrianSipos/dtn-demo-agent/>.
[github-dtn-wireshark] [github-dtn-wireshark]
Sipos, B., "Wireshark Dissectors for BPv7-related Sipos, B., "Wireshark Dissectors for BPv7-related
Protocols", Protocols",
<https://github.com/BSipos-RKF/dtn-wireshark/>. <https://github.com/BrianSipos/dtn-wireshark/>.
[LE-multi-perspective] [LE-multi-perspective]
Aas, J., McCarney, D., and R. Shoemaker, "Multi- Aas, J., McCarney, D., and R. Shoemaker, "Multi-
Perspective Validation Improves Domain Validation Perspective Validation Improves Domain Validation
Security", 19 February 2020, Security", 19 February 2020,
<https://letsencrypt.org/2020/02/19/multi-perspective- <https://letsencrypt.org/2020/02/19/multi-perspective-
validation.html>. validation.html>.
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
$admin-record /= [0xFFFF, acme-record] $admin-record /= [0xFFFF, acme-record]
acme-record = { acme-record = {
token-chal, id-chal,
token-bundle, token-bundle,
? key-auth-digest ; present for Response Bundles ? key-auth-digest ; present for Response Bundles
} }
token-chal = (1 => bstr) id-chal = (1 => bstr)
token-bundle = (2 => bstr) token-bundle = (2 => bstr)
key-auth-digest = (3 => bstr) key-auth-digest = (3 => bstr)
Appendix B. Example Authorization Appendix B. Example Authorization
[NOTE to the RFC Editor: The "0xFFFF" in these examples are replaced [NOTE to the RFC Editor: The "0xFFFF" in these examples are replaced
by the "ACME Node ID Validation" administrative record type code.] by the "ACME Node ID Validation" administrative record type code.]
This example is a bundle exchange for the ACME server with Node ID This example is a bundle exchange for the ACME server with Node ID
"dtn://acme-server/" performing a verification for ACME client Node "dtn://acme-server/" performing a verification for ACME client Node
skipping to change at page 28, line 15 skipping to change at page 29, line 12
challenge requires that the ACME client respond within a 60 second challenge requires that the ACME client respond within a 60 second
time window. time window.
[_ [_
[ [
7, / BP version / 7, / BP version /
0x22, / flags: user-app-ack, payload-is-an-admin-record / 0x22, / flags: user-app-ack, payload-is-an-admin-record /
0, / CRC type: none / 0, / CRC type: none /
[1, "//acme-client/"], / destination / [1, "//acme-client/"], / destination /
[1, "//acme-server/"], / source / [1, "//acme-server/"], / source /
[1, "//acme-server/"], / report-to / [1, 0], / report-to: none /
[1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 / [1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 /
60000 / lifetime: 60s / 60000 / lifetime: 60s /
], ],
[ [
1, / block type code / 1, / block type code /
1, / block number / 1, / block number /
0, / flags / 0, / flags /
0, / CRC type: none / 0, / CRC type: none /
<<[ / type-specific data / <<[ / type-specific data /
0xFFFF, / record-type-code / 0xFFFF, / record-type-code /
{ / record-content / { / record-content /
1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal / 1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle / 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle /
} }
]>> ]>>
] ]
] ]
Figure 2: Example Challenge Bundle Figure 2: Example Challenge Bundle
B.2. Response Bundle B.2. Response Bundle
skipping to change at page 29, line 24 skipping to change at page 30, line 24
30000 / lifetime: 30s / 30000 / lifetime: 30s /
], ],
[ [
1, / block type code / 1, / block type code /
1, / block number / 1, / block number /
0, / flags / 0, / flags /
0, / CRC type: none / 0, / CRC type: none /
<<[ / block-type-specific data / <<[ / block-type-specific data /
0xFFFF, / record-type-code / 0xFFFF, / record-type-code /
{ / record-content / { / record-content /
1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal / 1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle / 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /
3: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew' 3: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew'
/ key auth. digest / / key auth. digest /
} }
]>> ]>>
] ]
] ]
Figure 3: Example Response Bundle Figure 3: Example Response Bundle
Acknowledgments
This specification is based on DTN use cases related to PKIX
certificate issuance.
The workflow and terminology of this validation method was originally
copied from the work of Alexey Melnikov in [RFC8823].
Author's Address Author's Address
Brian Sipos Brian Sipos
RKF Engineering Solutions, LLC RKF Engineering Solutions, LLC
7500 Old Georgetown Road 7500 Old Georgetown Road
Suite 1275 Suite 1275
Bethesda, MD 20814-6198 Bethesda, MD 20814-6198
United States of America United States of America
Email: brian.sipos+ietf@gmail.com Email: brian.sipos+ietf@gmail.com
 End of changes. 62 change blocks. 
142 lines changed or deleted 206 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/