draft-ietf-acme-dtnnodeid-02.txt   draft-ietf-acme-dtnnodeid-03.txt 
Automated Certificate Management Environment B. Sipos Automated Certificate Management Environment B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Intended status: Experimental 16 April 2021 Intended status: Experimental 3 May 2021
Expires: 18 October 2021 Expires: 4 November 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-02 draft-ietf-acme-dtnnodeid-03
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 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 October 2021. This Internet-Draft will expire on 4 November 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
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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as 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 Simplified 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 . . . . . . . . . . . . . . . . . 4 1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 4
1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 6 2. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 7
3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 6 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 7
3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 9 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 10
3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 9 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 11
3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 10 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 12
3.4. ACME Node ID Validation Response Bundles . . . . . . . . 11 3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 13
3.5. Response Bundle Checks . . . . . . . . . . . . . . . . . 12 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 13
4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 13 3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 15
5. Certificate Request Profile . . . . . . . . . . . . . . . . . 14 4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 15
5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 14 5. Certificate Request Profile . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 14 Certificates . . . . . . . . . . . . . . . . . . . . . . 17
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Threat: Passive Leak of Validation Data . . . . . . . . . 15 7.1. Threat: Passive Leak of Validation Data . . . . . . . . . 18
7.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 16 7.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 18
7.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 16 7.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 18
7.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 17 7.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 17 8.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 20
8.2. ACME Validation Method . . . . . . . . . . . . . . . . . 17 8.2. ACME Validation Method . . . . . . . . . . . . . . . . . 20
8.3. BP Bundle Administrative Record Types . . . . . . . . . . 18 8.3. BP Bundle Administrative Record Types . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Administrative Record Types CDDL . . . . . . . . . . 21 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 24
Appendix B. Example Bundles . . . . . . . . . . . . . . . . . . 21 Appendix B. Example Authorization . . . . . . . . . . . . . . . 24
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 22 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 24
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 23 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
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 33 skipping to change at page 3, line 33
order containing a "uri", the client can finalize the order using an order containing a "uri", the client can finalize the order using an
associated certificate signing request (CSR). Because a single order associated certificate signing request (CSR). Because a single order
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 [I-D.ietf-acme-email-smime]. For that of secured email validation of [RFC8823].
that reason some token splitting terminology in this document is
taken from the email specification.
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
and their associated BP agent(s). This document only describes
exchanges between ACME client--server pairs and between their BP
agents.
* Specific BP extension blocks or BPSec security contexts necessary * Specific BP extension blocks or BPSec security contexts necessary
to fulfill the security requirements of this protocol. The exact to fulfill the security requirements of this protocol. The exact
security context needed, and their parameters, are network- security context needed, and their parameters, are network-
specific. specific.
* Policies or mechanisms for defining or configuring bundle * Policies or mechanisms for defining or configuring bundle
integrity gateways, or trusting integrity gateways on an integrity gateways, or trusting integrity gateways on an
individual entity or across a network. individual entity or across a network.
* Mechanisms for locating or identifying other bundle entities * Mechanisms for locating or identifying other bundle entities
skipping to change at page 4, line 48 skipping to change at page 4, line 52
descriptions of the rationale and capabilities of these networks can descriptions of the rationale and capabilities of these networks can
be found in "Delay-Tolerant Network Architecture" [RFC4838]. be found in "Delay-Tolerant Network Architecture" [RFC4838].
When a ACME client requests a pre-authorization or an order with a When a ACME client requests a pre-authorization or an order with a
"uri" having one of the DTN Node ID schemes, the ACME server offers a "uri" having one of the DTN Node ID schemes, the ACME server offers a
challenge type to validate that Node ID. If the ACME client attempts challenge type to validate that Node ID. If the ACME client attempts
the authorization challenge to validate a Node ID, the ACME server the authorization challenge to validate a Node ID, the ACME server
sends an ACME Node ID Validation Challenge Bundle with a destination sends an ACME Node ID Validation Challenge Bundle with a destination
of the Node ID being validated. The BP agent on that node receives of the Node ID being validated. The BP agent on that node receives
the Challenge Bundle, generates an ACME key authorization digest, and the Challenge Bundle, generates an ACME key authorization digest, and
sends an ACME Node ID Validation Response Bundle in reply. Finally, sends an ACME Node ID Validation Response Bundle in reply. An
the ACME server receives the Response Bundle and checks that the Integrity Gateway on the client side of the DTN can be used to attest
digest was generated for the associated ACME challenge and from the to the source of the Response Bundle. Finally, the ACME server
client account key associated with the original request. receives the Response Bundle and checks that the digest was generated
for the associated ACME challenge and from the client account key
associated with the original request. This workflow is shown in the
diagram of Figure 1 and defined in Section 3.
+------------+ +------------+
| ACME |<===== HTTPS exchanges =====>| ACME |
| Client | | Server |
+------------+ +------------+
| | ^
Enable or disable Send | |
challenge from server Challenge | | Indicate
| Non-DTN | | Response
--------------------------------------------------------------------
V DTN V |
++------------++ ++------------++
|| Admin Elem.|| || Admin Elem.||
|+------------+| |+------------+|
| Client's |<----- Challenge Bundle ---| Server's |
| BP Agent | | BP Agent |
+--------------+ +--------------+
| ^
| +-------------+ |
| | Integrity | |
+---->| Gateway |---Response Bundle----+
+-------------+
Figure 1: The relationships between Node ID Validation entities
Because the DTN Node ID is used both for routing bundles between BP Because the DTN Node ID is used both for routing bundles between BP
agents and for multiplexing services within a BP agent, there is no agents and for multiplexing administrative services within a BP
possibility to separate the ACME validation of a Node ID from normal agent, there is no possibility to separate the ACME validation of a
bundle handling on that same Node ID. This leaves Bundle Node ID from normal bundle handling for that same Node ID. This
administrative records as a way to leave the Node ID unchanged while leaves administrative record types as a way to leave the Node ID
disambiguating from normal service data bundles. unchanged while disambiguating from other service data bundles.
There is nothing in this protocol which requires network-topological
co-location of either the ACME client or ACME server with their
associated BP agent. While ACME requires a low-enough latency
network to perform HTTPS exchanges between ACME client and server,
the client's BP agent (the one being validated) could be on the far
side of a long-delay or multi-hop DTN network. The means by which
the ACME client or server communicates with its associated BP agent
is an implementation matter.
1.3. Use of CDDL 1.3. Use of CDDL
This document defines CBOR structure using the Concise Data This document defines CBOR structure using the Concise Data
Definition Language (CDDL) of [RFC8610]. The entire CDDL structure Definition Language (CDDL) of [RFC8610]. The entire CDDL structure
can be extracted from the XML version of this document using the can be extracted from the XML version of this document using the
XPath expression: XPath expression:
'//sourcecode[@type="cddl"]' '//sourcecode[@type="cddl"]'
skipping to change at page 7, line 6 skipping to change at page 8, line 6
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 URI by verifying that server validates control of the Node ID URI by verifying that
received Response Bundles correspond with the BP Node and client received Response Bundles correspond with the BP Node and client
account key being validated. account key being validated.
Similar to the ACME use case for validating email address ownership Similar to the ACME use case for validating email address ownership
[I-D.ietf-acme-email-smime], this challenge splits the token into two [RFC8823], this challenge splits the token into several parts, each
parts. Each part reaches the client through a different channel: one being transported by a different channel, and the Key Authorization
via the ACME channel in the challenge object, the other via the DTN result requires combining all parts of the token. The token parts
channel within the Challenge Bundle. The Key Authorization result are:
requires that the ACME client have access to the results of each
channel to get both parts of the token. "token-chal" This token is unique to, and constant for, each ACME
authorization. It is contained in the Challenge Object of
Section 3.1 as well as the Challenge Bundle of Section 3.3. It
ensures that the Key Authorization is bound to the specific ACME
challenge (and parent ACME authorization) and also allows the ACME
client's BP agent to filter-in only valid Challenge Bundles. This
token is also accessible to DTN on-path eavesdroppers.
"token-bundle" This token is unique to each Challenge Bundle sent by
the ACME server. It is contained in the Challenge Bundle of
Section 3.3 and ensures that the Key Authorization is bound to the
ability to receive the Challenge Bundle. This token is also
accessible to DTN on-path eavesdroppers.
The DTN Node ID Challenge SHALL only be allowed for URIs usable as a The DTN Node ID Challenge SHALL only be allowed for URIs usable as a
DTN Node ID, which are currently the schemes "dtn" and "ipn" as DTN Node ID, which are currently the schemes "dtn" and "ipn" as
defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node
ID validation, the ACME server SHALL define a challenge object in ID validation, the ACME server SHALL define a challenge object in
accordance with Section 3.1. Once this challenge object is defined, accordance with Section 3.1. Once this challenge object is defined,
the ACME client may begin the validation. 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 "uri" for the desired Node ID. From the identifier of type "uri" for the desired Node ID. From
either of these entry points an authorization for the "uri" type either of these entry points an authorization for the "uri" type
is indicated by the ACME server. See Section 7.4 of [RFC8555] is indicated by the ACME server. See Section 7.4 of [RFC8555]
for more details. for more details.
2. The ACME client obtains the challenge source Node ID and <token- 2. The ACME client obtains the challenge source Node ID and "token-
part2> from the challenge object in accordance with Section 3.1. chal" from the challenge object in accordance with Section 3.1.
3. The ACME client indicates to the BP agent the source Node ID and 3. The ACME client indicates to the administrative element of its BP
challenge <token-part2> which is authorized for use and the agent the source Node ID and challenge "token-chal" which is
associated client account key fingerprint. authorized for use and the associated client account key
thumbprint. The ACME client SHALL wait, if necessary, until the
agent is 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 ACME client waits for indication from the BP agent that a 5. The administrative element waits for a Challenge Bundle to be
Challenge Bundle has been received, including its <token-part1> received with the authorized ACME parameters, including its
payload. "token-bundle" payload, in accordance with Section 3.3.
6. The ACME client concatenates <token-part1> with <token-part2> (as 6. The administrative element concatenates "token-bundle" with
text strings) and computes the Key Authorization in accordance "token-chal" (each as base64url-encoded text strings) and
with Section 8.1 of [RFC8555] using the full token and client computes the Key Authorization in accordance with Section 8.1 of
account key fingerprint. [RFC8555] using the full token and client account key thumbprint.
7. The ACME client indicates to the BP agent the SHA-256 digest of 7. The administrative element computes the SHA-256 digest of the Key
the Key Authorization result, which results in a Response Bundle Authorization result and generates a Response Bundle to send back
being sent back to the ACME server in accordance with to the ACME server in accordance with Section 3.4.
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 validation source and
<token-part2> is no longer usable. "token-chal" is no longer usable. If the authorization fails,
the ACME client MAY retry 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 "uri", where the URI value is a Node ID. the identifier of type "uri", where the URI value is a Node 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" and a <token-part2>. challenge type "dtn-nodeid-01" in accordance with Section 3.1.
3. The ACME server sends one or more Challenge Bundles in accordance 3. The ACME server receives a POST to the challenge URL indicated
with Section 3.3. Each challenge bundle SHALL contain a distinct from the authorization object. The payload is handled in
<token-part1> to be able to correlate with a response bundle. accordance with Section 3.2.
4. The ACME server sends, via the administrative element of its BP
agent, one or more Challenge Bundles in accordance with
Section 3.3. Each challenge bundle SHALL contain a distinct
"token-bundle" to be able to correlate with a response bundle.
Computing an expected Key Authorization digest is not necessary Computing an expected Key Authorization digest is not necessary
until a response is received. until a response is received.
4. The ACME server waits for Response Bundle(s) for a limited 5. The ACME server waits for Response Bundle(s) for a limited
interval of time. A default response interval, used when the interval of time (based on the challenge response object).
challenge does not contain an RTT, SHOULD be a configurable Responses are encoded in accordance with Section 3.4.
parameter of the ACME server. If the ACME client indicated an
RTT value in the challenge object, the response interval SHOULD
be twice the RTT (with limiting logic applied as described
below). The lower limit on response waiting time is network-
specific, but SHOULD NOT be shorter than one second. The upper
limit on response waiting time is network-specific, but SHOULD
NOT be longer than one minute (60 seconds) for a terrestrial-only
DTN. Responses are encoded in accordance with Section 3.4.
5. 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.5. 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
validation procedure is successful only if all responses are validation procedure is successful only if all responses are
successful. successful. If validation is not successful, a client may retry
the challenge which starts in Step 3.
An ACME server MAY send multiple challenges from different origins in An ACME server MAY send multiple challenges from different origins in
the DTN network to avoid possible on-path attacks, as recommended in the DTN network to avoid possible on-path attacks, as recommended in
Section 10.2 of [RFC8555]. If responses are received from multiple Section 10.2 of [RFC8555]. If responses are received from multiple
challenges, any response failure SHALL cause a failure of the overall challenges, any response failure SHALL cause a failure of the overall
validation. Each response failure MAY be indicated to the ACME validation. Each response failure MAY be indicated to the ACME
client as a validation subproblem. client as a validation subproblem.
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, only for
the Node ID, and only for the validation token indicated by the ACME the Node ID, and only for the "token-chal" indicated by the ACME
client. A BP agent SHALL respond to multiple challenges with the client. A BP agent SHALL respond to multiple challenges with the
same parameters. These correspond with the ACME server validating same parameters. These correspond with the ACME server validating
via multiple routing paths. via multiple routing 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, string): The source Node ID of bundles originating source (required, string): The source Node ID of bundles originating
at the ACME server as a text URI. at the ACME server as a text URI.
token-part2 (required, string): A random value that uniquely token-chal (required, string): A random value that uniquely
identifies the challenge. This value MUST have at least 128 bits identifies the challenge. This value MUST have at least 128 bits
of entropy. It MUST NOT contain any characters outside the of entropy. It MUST NOT contain any characters outside the
base64url alphabet as described in Section 5 of [RFC4648]. base64url alphabet as described in Section 5 of [RFC4648].
Trailing '=' padding characters MUST be stripped. See [RFC4086] Trailing '=' padding characters MUST be stripped. See [RFC4086]
for additional information on randomness requirements. 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://example-acme-server/", "source": "dtn://acme-server/",
"token-part2": "tPUZNY4ONIk6LxErRFEjVw" "token-chal": "tPUZNY4ONIk6LxErRFEjVw"
} }
The "token-chal" value included in this object is fixed for the
The <token-part2> value included in this object is fixed for the entire challenge, and may correspond with multiple separate "token-
entire challenge, and may correspond with multiple separate <token- bundle" values when multiple Challenge Bundles are sent for a single
part1> 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
validation round-trip is expected to take longer than normal network validation round-trip is expected to take longer than normal network
delays (on the order of seconds). delays (on the order of seconds).
skipping to change at page 10, line 27 skipping to change at page 11, line 40
} }
A challenge response is not sent until the BP agent has been A challenge response is not sent until the BP agent has been
configured to properly respond to the challenge, so the RTT value is configured to properly respond to the challenge, so the RTT value is
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
contain an RTT, SHOULD be a configurable parameter of the ACME
server. If the ACME client indicated an RTT value in the object, the
response interval SHOULD be twice the RTT (with limiting logic
applied as described below). The lower limit on response waiting
time is network-specific, but SHOULD NOT be shorter than one second.
The upper limit on response waiting time is network-specific, but
SHOULD NOT be longer than one minute (60 seconds) for a terrestrial-
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
primary block flags SHALL indicate that user application primary block flags SHALL indicate that user application
skipping to change at page 10, line 49 skipping to change at page 12, line 27
flags MAY indicate that status reports are requested; such status flags MAY indicate that status reports are requested; such status
can be helpful to troubleshoot routing issues. can be helpful to troubleshoot routing issues.
Destination EID: The Destination EID SHALL be identical to the Node Destination EID: The Destination EID SHALL be identical to the Node
ID being validated. The ACME server SHOULD NOT perform URI ID being validated. The ACME server SHOULD NOT perform URI
normalization on the Node ID given by the ACME client. normalization on the Node ID given by the ACME client.
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.
Report-to Node ID: The Report-to Node ID SHALL indicate the Node ID
of the ACME server performing the challenge if status reports are
requested.
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 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 one pair: record content SHALL consist of a CBOR map containing two pairs:
* The pair SHALL consist of key 1 with value of ACME challenge * One pair SHALL consist of key 1 with value of ACME challenge
token-part1, represented as a CBOR byte string. The token- "token-chal", copied from the challenge object, represented as
part1 is a random value that uniquely identifies the challenge a CBOR byte string.
bundle. This value MUST have at least 128 bits of entropy.
See [RFC4086] for additional information on randomness * One pair SHALL consist of key 2 with value of ACME challenge
requirements. "token-bundle", represented as a CBOR byte string. The "token-
bundle" is a random value that uniquely identifies the
challenge bundle. This value MUST have at least 128 bits of
entropy. See [RFC4086] for additional information on
randomness 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-
synchronized clock or the agent responding to the challenge is
expected to not have a well-synchronized clock, the bundle SHALL
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. An ACME client BP agent SHALL NOT respond accordance with Section 4 or with a Security Source identical to the
to a Challenge Bundle which does not have a BIB-covered payload. An bundle Source Node. Challenge Bundles SHALL NOT be directly
ACME client BP agent SHALL NOT respond to a Challenge Bundle with a encrypted by Block Confidentiality Block (BCB) or any other method
BIB which has a security source which is untrusted or has signature (see Section 7.1).
which fails to verify.
Challenge Bundles SHALL NOT be directly encrypted by Block 3.3.1. Challenge Bundle Checks
Confidentiality Block (BCB) or any other method (see Section 7.1).
A proper Challenge Bundle meets all of the following criteria:
* The Challenge Bundle was received within the time interval allowed
for the challenge.
* 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 [RFC3986] and scheme-based
normalization of those schemes specified in [I-D.ietf-dtn-bpbis].
* The Challenge Bundle contains a BIB which covers at least the
primary block and payload. That BIB has a security source which
is trusted and passes security-context-specific validation (i.e.
MAC or signature verification).
* The challenge payload contains the "token-chal" as indicated in
the ACME challenge object. The challenge payload contains a
"token-bundle" meeting the definition in Section 3.3.
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
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 Each ACME Node ID Validation Response Bundle SHALL be structured Each Each ACME Node ID Validation Response Bundle SHALL be structured
and encoded in accordance with [I-D.ietf-dtn-bpbis]. and 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
skipping to change at page 12, line 20 skipping to change at page 14, line 28
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 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 two 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-part1, 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 the SHA-256 * One pair SHALL consist of key 2 with value of ACME challenge
"token-bundle", copied from the Request Bundle, represented as
a CBOR byte string.
* 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.
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
Response Bundles SHOULD include a BIB in accordance with Section 4. If the BP agent responding to a Challenge Bundle does not have a
An ACME server BP agent SHOULD NOT accept a Response Bundle which well-synchronized clock, it SHALL use any information about last-hop
does not have a BIB-covered payload. An ACME server BP agent SHALL delays and (if present) Bundle Age extension data to infer the age of
NOT accept a Response Bundle Bundle with a BIB which has a security the Challenge Bundle and lifetime of the Response Bundle.
source which is untrusted or has signature which fails to verify.
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 7.1 for explanation).
3.5. 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
comparison logic of [RFC3986] and scheme-based normalization of comparison logic of [RFC3986] and scheme-based normalization of
those schemes specified in [I-D.ietf-dtn-bpbis]. those schemes specified in [I-D.ietf-dtn-bpbis].
* The response payload contains the <token-part1> as sent in the * The Response Bundle contains a BIB which covers at least the
Challenge Bundle. The response payload contains the expected Key primary block and payload. That BIB has a security source which
Authorization digest computed by the ACME server. Because is trusted and passes security-context-specific validation.
multiple Challenge Bundles can be sent to validate the same Node
ID, the <token-part1> in the response is needed to correlate with * The response payload contains the "token-chal" and "token-bundle"
the expected Key Authorization digest. as sent in the Challenge Bundle. The response payload contains
the expected Key Authorization digest computed by the ACME server.
Because multiple Challenge Bundles can be sent to validate the
same Node ID, the "token-bundle" in the response is needed to
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. Any of
the failures above SHOULD be indicated as subproblems to the ACME the failures above SHOULD be indicated as subproblems to the ACME
client. client.
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 vouches for the origination of a bundle by adding a
skipping to change at page 16, line 40 skipping to change at page 19, line 9
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
uniqueness of each <token-part1> to each challenge bundle ensures uniqueness of each "token-bundle" to each challenge bundle ensures
that the Key Authorization is unique to the challenge bundle. The that the Key Authorization is unique to the challenge bundle. The
uniqueness of each <token-part2> 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 7.4.
skipping to change at page 18, line 33 skipping to change at page 21, line 8
+=========================+=======+==============+===============+ +=========================+=======+==============+===============+
| 7 | TBD | ACME Node ID | This | | 7 | TBD | ACME Node ID | This |
| | | Validation | specification | | | | Validation | specification |
+-------------------------+-------+--------------+---------------+ +-------------------------+-------+--------------+---------------+
Table 3 Table 3
9. Acknowledgments 9. Acknowledgments
This specification is based on DTN use cases related to PKIX This specification is based on DTN use cases related to PKIX
certificate generation. certificate issuance.
The workflow and terminology of this validation method was originally
copied from the work of Alexey Melnikov in [RFC8823].
10. References 10. References
10.1. Normative References 10.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>.
skipping to change at page 20, line 21 skipping to change at page 22, line 46
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Burleigh, S., Fall, K., and E. J. Birrane, "Bundle
Version 7", Work in Progress, Internet-Draft, draft-ietf- Protocol Version 7", Work in Progress, Internet-Draft,
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]
Birrane, E. 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-26, 8 January 2021, ietf-dtn-bpsec-27, 16 February 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-bpsec-26>. <https://tools.ietf.org/html/draft-ietf-dtn-bpsec-27>.
10.2. Informative References 10.2. Informative References
[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>.
[I-D.ietf-acme-email-smime] [RFC8823] Melnikov, A., "Extensions to Automatic Certificate
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,
Work in Progress, Internet-Draft, draft-ietf-acme-email- <https://www.rfc-editor.org/info/rfc8823>.
smime-13, 20 November 2020, <https://tools.ietf.org/html/
draft-ietf-acme-email-smime-13>.
[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>.
[I-D.ietf-dtn-tcpclv4] [I-D.ietf-dtn-tcpclv4]
Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
Tolerant Networking TCP Convergence Layer Protocol Version Tolerant Networking TCP Convergence Layer Protocol Version
4", Work in Progress, Internet-Draft, draft-ietf-dtn- 4", Work in Progress, Internet-Draft, draft-ietf-dtn-
tcpclv4-24, 7 December 2020, tcpclv4-26, 15 February 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-24>. <https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-26>.
[I-D.sipos-dtn-udpcl] [I-D.sipos-dtn-udpcl]
Sipos, B., "Delay-Tolerant Networking UDP Convergence Sipos, B., "Delay-Tolerant Networking UDP Convergence
Layer Protocol", Work in Progress, Internet-Draft, draft- Layer Protocol", Work in Progress, Internet-Draft, draft-
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
Contexts", Work in Progress, Internet-Draft, draft-bsipos- Context", Work in Progress, Internet-Draft, draft-bsipos-
dtn-bpsec-cose-04, 22 December 2020, 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-
04>. 05>.
[github-acme-dtnnodeid] [github-acme-dtnnodeid]
Sipos, B., "ACME Node ID Example Implementation", Sipos, B., "ACME Node ID Example Implementation",
<https://github.com/BSipos-RKF/acme-dtnnodeid/>. <https://github.com/BSipos-RKF/acme-dtnnodeid/>.
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-part1, token-chal,
token-bundle,
? key-auth-digest ; present for Response Bundles ? key-auth-digest ; present for Response Bundles
} }
token-part1 = (1 => bstr) token-chal = (1 => bstr)
key-auth-digest = (2 => bstr) token-bundle = (2 => bstr)
key-auth-digest = (3 => bstr)
Appendix B. Example Bundles 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
ID "dtn://acme-client/". The example bundles use no block CRC or ID "dtn://acme-client/". The example bundles use no block CRC or
BPSec integrity, which is for simplicity and is not recommended for BPSec integrity, which is for simplicity and is not recommended for
normal use. The provided figures are extended diagnostic notation normal use. The provided figures are extended diagnostic notation
[RFC8610]. [RFC8610].
For this example the ACME client key thumbprint has the base64url For this example the ACME client key thumbprint has the base64url
encoded value of: encoded value of:
skipping to change at page 22, line 16 skipping to change at page 24, line 41
ID "dtn://acme-client/". The example bundles use no block CRC or ID "dtn://acme-client/". The example bundles use no block CRC or
BPSec integrity, which is for simplicity and is not recommended for BPSec integrity, which is for simplicity and is not recommended for
normal use. The provided figures are extended diagnostic notation normal use. The provided figures are extended diagnostic notation
[RFC8610]. [RFC8610].
For this example the ACME client key thumbprint has the base64url For this example the ACME client key thumbprint has the base64url
encoded value of: encoded value of:
"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
And the ACME-server generated token-part2 (transported to the ACME And the ACME-server generated "token-chal" has the base64url-encoded
client via HTTPS) has the base64url-encoded value of: value of:
"tPUZNY4ONIk6LxErRFEjVw" "tPUZNY4ONIk6LxErRFEjVw"
B.1. Challenge Bundle B.1. Challenge Bundle
For the single challenge bundle in this example, the token-part1 For the single challenge bundle in this example, the "token-bundle"
(transported as byte string via BP) has the base64url-encoded value (transported as byte string via BP) has the base64url-encoded value
of: of:
"p3yRYFU4KxwQaHQjJ2RdiQ" "p3yRYFU4KxwQaHQjJ2RdiQ"
The minimal-but-valid Challenge Bundle is shown in Figure 2. This
The minimal-but-valid Challenge Bundle is shown in Figure 1. This
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 /
skipping to change at page 23, line 24 skipping to change at page 25, line 27
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'p3yRYFU4KxwQaHQjJ2RdiQ' / token-part1 / 1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal /
2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle /
} }
]>> ]>>
] ]
] ]
Figure 1: Example Challenge Bundle Figure 2: Example Challenge Bundle
B.2. Response Bundle B.2. Response Bundle
When the tokens are combined with the key fingerprint, the full Key When the tokens are combined with the key thumbprint, the full Key
Authorization value (a single string split across lines for Authorization value (a single string split across lines for
readability) is: readability) is:
"p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw." "p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw."
"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
The minimal-but-valid Response Bundle is shown in Figure 2. This The minimal-but-valid Response Bundle is shown in Figure 3. This
response indicates that there is 30 seconds remaining in the response response indicates that there is 30 seconds remaining in the response
time window. time window.
[ [
[ [
7, / BP version / 7, / BP version /
0x02, / flags: payload-is-an-admin-record / 0x02, / flags: payload-is-an-admin-record /
0, / CRC type: none / 0, / CRC type: none /
[1, "//acme-server/"], / destination / [1, "//acme-server/"], / destination /
[1, "//acme-client/"], / source / [1, "//acme-client/"], / source /
skipping to change at page 24, line 24 skipping to change at page 26, 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'p3yRYFU4KxwQaHQjJ2RdiQ', / token-part1 / 1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal /
2: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew' 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle /
3: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew'
/ key auth. digest / / key auth. digest /
} }
]>> ]>>
] ]
] ]
Figure 2: Example Response Bundle Figure 3: Example Response Bundle
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
 End of changes. 62 change blocks. 
166 lines changed or deleted 265 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/