draft-ietf-acme-dtnnodeid-00.txt   draft-ietf-acme-dtnnodeid-01.txt 
Delay-Tolerant Networking B. Sipos Automated Certificate Management Environment B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Intended status: Experimental 26 August 2020 Intended status: Experimental 7 March 2021
Expires: 27 February 2021 Expires: 8 September 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-00 draft-ietf-acme-dtnnodeid-01
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 27 February 2021. This Internet-Draft will expire on 8 September 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Authorization Strategy . . . . . . . . . . . . . . . . . 3 1.1. Authorization Strategy . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 4 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 5
4. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 5 2. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 5
4.1. DTN Node ID Challenge Request Object . . . . . . . . . . 7 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 6
4.2. DTN Node ID Challenge Response Object . . . . . . . . . . 8 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 8
4.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 8 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 9
4.4. ACME Node ID Validation Response Bundles . . . . . . . . 9 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 9
4.5. Response Bundle Checks . . . . . . . . . . . . . . . . . 10 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 10
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 3.5. Response Bundle Checks . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Certificate Request Profile . . . . . . . . . . . . . . . . . 12
6.1. Threat: Passive Leak of Bundle Data . . . . . . . . . . . 11 4.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 12
6.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 12 4.2. Generating Encryption-only or Signing-only Bundle Security
6.3. Threat: Denial of Service . . . . . . . . . . . . . . . . 12 Certificates . . . . . . . . . . . . . . . . . . . . . . 13
6.4. Multiple Certificate Claims . . . . . . . . . . . . . . . 12 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 13 6.1. Threat: Passive Leak of Validation Data . . . . . . . . . 14
7.2. ACME Validation Method . . . . . . . . . . . . . . . . . 13 6.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 14
7.3. BP Bundle Administrative Record Types . . . . . . . . . . 13 6.3. Threat: Denial of Service . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. ACME Validation Method . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 7.3. BP Bundle Administrative Record Types . . . . . . . . . . 15
Appendix A. Administrative Record Types CDDL . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Example Bundles . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 19
Appendix B. Example Bundles . . . . . . . . . . . . . . . . . . 19
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 19
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
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 19 skipping to change at page 3, line 27
schemes, and determines how bundles are routed within a DTN. schemes, and determines how bundles are routed within a DTN.
Currently the schemes "dtn" and "ipn" as defined in Currently the schemes "dtn" and "ipn" as defined in
[I-D.ietf-dtn-bpbis] are valid for a Node ID. [I-D.ietf-dtn-bpbis] are valid for a Node ID.
Once an ACME server validates a Node ID, either as a pre- Once an ACME server validates a Node ID, either as a pre-
authorization of the "uri" or as one of the authorizations of an authorization of the "uri" or as one of the authorizations of an
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. Because a single order can associated certificate signing request. Because a single order can
contain multiple identifiers of multiple types, there can be 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 6.4. to, validate those multiple identifiers as described in Section 4.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 BP agent with the new certificate is an implementation configures the BP agent with the new certificate is an implementation
matter. 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 [I-D.ietf-acme-email-smime]. For
that reason some token splitting terminology in this document is that reason some token splitting terminology in this document is
taken from the email specification. taken from the email specification.
1.1. Authorization Strategy 1.1. Authorization Strategy
The basic unit of data exchange in a DTN is a Bundle The basic unit of data exchange in a DTN is a Bundle
[I-D.ietf-dtn-bpbis], which consists of a data payload with [I-D.ietf-dtn-bpbis], which consists of a data payload with
accompanying metadata. A Node ID is used to identify the source and accompanying metadata. An Endpoint ID is used as the destination of
destination of a Bundle and is used for routing through intermediate a Bundle and can indicate both a unicast or a multicast destination.
nodes. More detailed descriptions of the rationale and capabilities A Node ID is used to identify the source of a Bundle and is used for
of these networks can be found in "Delay-Tolerant Network routing through intermediate nodes, including the final node(s) used
Architecture" [RFC4838]. to deliver a Bundle to its destination endpoint. A Node ID can also
be used as an endpoint for administrative bundles. More detailed
descriptions of the rationale and capabilities of these networks can
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" which could be used as a DTN Node ID, the ACME server offers a "uri" which could be used as a DTN Node ID, 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 signature, and sends an ACME the Challenge Bundle, generates an ACME signature, and sends an ACME
Node ID Validation Response Bundle with the signature. Finally, the Node ID Validation Response Bundle with the signature. Finally, the
ACME server receives the Response Bundle and checks that the ACME server receives the Response Bundle and checks that the
signature came from the client account key associated with the signature came from the client account key associated with the
original request. original request.
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 services within a BP agent, there is no
possibility to separate the ACME validation of a Node ID from normal possibility to separate the ACME validation of a Node ID from normal
bundle handling on that same Node ID. This leaves Bundle bundle handling on that same Node ID. This leaves Bundle
administrative records as a way to leave the Node ID unchanged while administrative records as a way to leave the Node ID unchanged while
disambiguating from normal service data bundles. disambiguating from normal service data bundles.
2. Terminology 1.2. 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.
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:
skipping to change at page 4, line 39 skipping to change at page 5, line 5
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 ACME Validation Challenge Bundle". It is a Bundle created by the ACME
server to challenge a Node ID claim. 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.
3. URI ACME Identifier 1.3. Use of CDDL
This document defines CBOR structure using the Concise Data
Definition Language (CDDL) of [RFC8610]. The entire CDDL structure
can be extracted from the XML version of this document using the
XPath expression:
'//sourcecode[@type="cddl"]'
The following initial fragment defines the top-level symbols of this
document's CDDL, which includes the example CBOR content.
start = acme-record / bundle / tstr
2. URI ACME Identifier
This specification is the first to make use of a URI to identify a This specification is the first to make use of a URI to identify a
service for a certificate request in ACME. The URI-type identifier service for a certificate request in ACME. The URI-type identifier
is general purpose, and validating ownership of a URI requires a is general purpose, and validating ownership of a URI requires a
specific purpose related to its "scheme" component. In this specific purpose related to its "scheme" component. In this
document, the only purpose for which a URI ACME identifier is document, the only purpose for which a URI ACME identifier is
validated is as a DTN Node ID (see Section 4), but other validated is as a DTN Node ID (see Section 3), but other
specifications can define challenge types for other URI uses. specifications can define challenge types for other URI uses.
Identifiers of type "uri" MUST appear in an extensionRequest Identifiers of type "uri" MUST appear in an extensionRequest
attribute [RFC2985] requesting a subjectAltName extension of type attribute [RFC2985] requesting a subjectAltName extension of type
uniformResourceIdentifier having a value consistent with the uniformResourceIdentifier having a value consistent with the
requirements of [RFC3986]. requirements of [RFC3986].
Any identifier of type "uri" in a newOrder request MUST NOT have a
wildcard ("*") character in its value.
If an ACME server wishes to request proof that a user controls a URI, If an ACME server wishes to request proof that a user controls a URI,
it SHALL create an authorization with the identifier type "uri". The it SHALL create an authorization with the identifier type "uri". The
value field of the identifier SHALL contain the textual form of the value field of the identifier SHALL contain the textual form of the
URI as defined in Section 3 of [RFC3986]. The ACME server SHALL NOT URI as defined in Section 3 of [RFC3986]. The ACME server SHALL NOT
decode or attempt to dereference the URI value on its own. It is the decode or attempt to dereference the URI value on its own. It is the
responsibility of a validation method to ensure the URI ownership via responsibility of a validation method to ensure the URI ownership via
scheme-specific means authorized by the ACME client. scheme-specific means authorized by the ACME client.
An identifier for the URL "dtn://example/service" would be formatted An identifier for the Node ID of "dtn://example/" would be formatted
as: as:
{"type": "uri", "value": "dtn://example/service"} {"type": "uri", "value": "dtn://example/"}
4. 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 [I-D.ietf-acme-email-smime], this challenge splits the token into two
parts. Each part reaches the client through a different channel: one parts. Each part reaches the client through a different channel: one
via the ACME channel in the challenge object, the other via the DTN via the ACME channel in the challenge object, the other via the DTN
channel within the Challenge Bundle. The Key Authorization result channel within the Challenge Bundle. The Key Authorization result
requires that the ACME client have access to the results of each requires that the ACME client have access to the results of each
channel to get both parts of the token. channel to get both parts of the token.
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 4.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 obtains the challenge <token-part2> from the 1. The ACME client POSTs a newOrder or newAuthz request including
challenge object in accordance with Section 4.1. the identifier of type "uri" for the desired Node ID. From
either of these entry points an authorization for the "uri" type
is indicated by the ACME server. See Section 7.4 of [RFC8555]
for more details.
2. The ACME client indicates to the BP agent the challenge <token- 2. The ACME client obtains the challenge source Node ID and <token-
part2> which is authorized for use. part2> from the challenge object in accordance with Section 3.1.
3. The ACME client POSTs a challenge response to the challenge URL 3. The ACME client indicates to the BP agent the source and
challenge <token-part2> which is authorized for use.
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 4.2. The payload object is constructed in accordance with Section 3.2.
4. The ACME client waits for indication from the BP agent that a 5. The ACME client waits for indication from the BP agent that a
Challenge Bundle has been received, including its <token-part1> Challenge Bundle has been received, including its <token-part1>
payload. payload.
5. The ACME client concatenates <token-part1> with <token-part2> and 6. The ACME client concatenates <token-part1> with <token-part2> (as
computes the Key Authorization in accordance with Section 8.1 of text strings) and computes the Key Authorization in accordance
[RFC8555] using the full token and client account key. with Section 8.1 of [RFC8555] using the full token and client
account key digest.
6. The ACME client indicates to the BP agent the Key Authorization 7. The ACME client indicates to the BP agent the SHA-256 digest of
result, which will result in a Response Bundle being sent back to the Key Authorization result, which results in a Response Bundle
the ACME server. being sent back to the ACME server in accordance with
Section 3.4.
7. 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].
8. 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 <token- client indicates to the BP agent that the validation source and
part1> is no longer usable. <token-part2> is no longer usable.
Upon receiving a challenge response from an ACME client, the ACME The ACME server verifies the client's control over a Node ID by
server verifies the client's control over the Node ID by performing performing the following steps:
the following steps:
1. The ACME server generates the two-part challenge token and 1. The ACME server receives a newOrder or newAuthz request including
computes the expected Key Authorization in accordance with the identifier of type "uri", where the URI value is a Node ID.
Section 8.1 of [RFC8555] using the concatenated token and client
account key.
2. The ACME server sends one or more Challenge Bundles in accordance 2. The ACME server generates an authorization for the Node ID with
with Section 4.3. challenge type "dtn-nodeid-01" and a <token-part2>.
3. The ACME server waits for Response Bundle(s) for a limited 3. The ACME server sends one or more Challenge Bundles in accordance
with Section 3.3. Each challenge bundle SHALL contain a distinct
<token-part1> to be able to correlate with a response bundle.
Computing an expected Key Authorization digest is not necessary
until a response is received.
4. The ACME server waits for Response Bundle(s) for a limited
interval of time. A default response interval, used when the interval of time. A default response interval, used when the
challenge does not contain an RTT, SHOULD be a configurable challenge does not contain an RTT, SHOULD be a configurable
parameter of the ACME server. If the ACME client indicated an parameter of the ACME server. If the ACME client indicated an
RTT value in the challenge object, the response interval SHOULD RTT value in the challenge object, the response interval SHOULD
be twice the RTT (with limiting logic applied as described be twice the RTT (with limiting logic applied as described
below). The lower limit on response waiting time is network- below). The lower limit on response waiting time is network-
specific, but SHOULD NOT be shorter than one second. The upper specific, but SHOULD NOT be shorter than one second. The upper
limit on response waiting time is network-specific, but SHOULD limit on response waiting time is network-specific, but SHOULD
NOT be longer than one minute (60 seconds) for a terrestrial-only NOT be longer than one minute (60 seconds) for a terrestrial-only
DTN. Responses are encoded in accordance with Section 4.4. DTN. Responses are encoded in accordance with Section 3.4.
4. Once received and decoded, the ACME server checks the contents of 5. Once received and decoded, the ACME server checks the contents of
each Response Bundle in accordance with Section 4.5. After all each Response Bundle in accordance with Section 3.5. 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.
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 man-in-the-middle (MitM) attacks, the DTN network to avoid possible on-path attacks, as recommended in
as recommended in Section 10.2 of [RFC8555]. If responses are Section 10.2 of [RFC8555]. If responses are received from multiple
received from multiple challenges, any response failure SHALL cause a challenges, any response failure SHALL cause a failure of the overall
failure of the overall validation. Each response failure MAY be validation. Each response failure MAY be indicated to the ACME
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 4.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 validation token 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.
4.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
at the ACME server as a text URI.
token-part2 (required, string): A random value that uniquely token-part2 (required, string): A random value that uniquely
identifies the challenge. This value MUST have at least 64 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",
"status": "pending", "source": "dtn://example-acme-server/",
"token-part2": "qXjSp7npR2Y" "token-part2": "tPUZNY4ONIk6LxErRFEjVw"
} }
The only over-the-wire data required by ACME for a Challenge Bundle The only over-the-wire data required by ACME for a Challenge Bundle
is a nonce token, but the response data needs a client account key to is a nonce token, split into two parts, but the response data needs a
generate the Key Authorization. The client account key is kept client account key to generate the Key Authorization and its digest.
within the ACME client, the BP agent needs only the derived Key The client account key is kept within the ACME client, the BP agent
Authorization for its Response Bundle. needs only the derived key thumbprint for its Response Bundle.
4.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).
The DTN Node ID Challenge response object has the following content: The DTN Node ID Challenge response object has the following content:
skipping to change at page 8, line 38 skipping to change at page 9, line 38
{ {
"rtt": 300.0 "rtt": 300.0
} }
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 is likely to attempt server and the BP agent, and the ACME server can attempt some path
some path diversity, the RTT value SHOULD be pessimistic. diversity, the RTT value SHOULD be pessimistic.
4.3. ACME Node ID Validation Challenge Bundles 3.3. ACME Node ID Validation Challenge Bundles
Each ACME Node ID Validation Challenge Bundle has parameters as Each ACME Node ID Validation Challenge Bundle has parameters as
listed here: listed here:
Bundle Processing Control Flags: The payload SHALL be indicated as Bundle Processing Control Flags: The primary block flags SHALL
an administrative record. indicate that the payload is an administrative record. The
primary block flags SHALL indicate that user application
acknowledgement is requested; this flag distinguishes the
Challenge Bundle from the Response Bundle. The primary block
flags MAY 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 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 EID: The Source Node EID SHALL indicate the Endpoint ID Source Node ID: The Source Node ID SHALL indicate the Node ID of the
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 by this specification. type code defined in Section 7.3.
Administrative Record Content: The ACME challenge administrative
record content SHALL consist of a CBOR array with two elements.
The first element SHALL be a challenge indicator value 1,
represented as a CBOR unsigned integer. The second element SHALL
be the ACME challenge token-part1, represented as a CBOR text
string. The token-part1 is a random value that uniquely
identifies the challenge. This value MUST have at least 64 bits
of entropy. See [RFC4086] for additional information on
randomness requirements.
An ACME challenge administrative record would have CBOR diagnostic Administrative Record Content: The Challenge Bundle administrative
notation as: record content SHALL consist of a CBOR map containing one pair.
The pair SHALL consist of key 1 with value of ACME challenge
token-part1, represented as a CBOR byte string. The token-part1
is a random value that uniquely identifies the challenge. This
value MUST have at least 128 bits of entropy. See [RFC4086] for
additional information on randomness requirements.
[ An example full Challenge Bundle is included in Appendix B.1
1, / challenge indicator /
"LVMo24VdNAw" / token-part1 /
]
Challenge Bundles SHOULD be BIB-signed in accordance with Challenge Bundles SHOULD be BIB-signed in accordance with
[I-D.ietf-dtn-bpsec] if the ACME server is capable of signing [I-D.ietf-dtn-bpsec] if the ACME server is capable of signing
bundles. BP agents MAY refuse to respond to a Challenge Bundle which bundles. BP agents SHALL refuse to respond to a Challenge Bundle
is signed by a known ACME server but has an invalid signature. which is signed by a known ACME server but has an invalid signature.
Challenge Bundles SHOULD NOT be directly encrypted (by BCB or any Challenge Bundles SHOULD NOT be directly encrypted (by BCB or any
other method). other method).
4.4. ACME Node ID Validation Response Bundles 3.4. ACME Node ID Validation Response Bundles
Each ACME Node ID Validation Response Bundle has parameters as listed Each ACME Node ID Validation Response Bundle has parameters as listed
here: here:
Bundle Processing Control Flags: The payload SHALL be indicated as Bundle Processing Control Flags: The primary block flags SHALL
an administrative record. indicate that the payload is an administrative record. The
primary block flags SHALL NOT indicate that user application
acknowledgement is requested; this flag distinguishes the Response
Bundle from the Challenge Bundle. The primary block flags MAY
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 EID of the Challenge Bundle to which this response Source Node ID of the Challenge Bundle to which this response
corresponds. corresponds.
Source Node EID: The Source Node EID SHALL be identical to the the Source Node ID: The Source Node ID SHALL be identical to the the
Destination EID of the Challenge Bundle to which this response Destination EID of the Challenge Bundle to which this response
corresponds. corresponds.
Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set
to the time at which the response was generated. The response to the time at which the response was generated. The response
Lifetime SHALL indicate the response interval remaining if the Lifetime SHALL indicate the response interval remaining if the
Challenge Bundle indicated a limited Lifetime. Challenge Bundle indicated a limited Lifetime.
Administrative Record Type Code: Set to the ACME Node ID Validation Administrative Record Type Code: Set to the ACME Node ID Validation
type code defined by this specification. type code defined in Section 7.3.
Administrative Record Content: The ACME response administrative
record content SHALL consist of a CBOR array with two elements.
The first element SHALL be a response indicator value 2,
represented as a CBOR unsigned integer. The second element SHALL
be the ACME Key Authorization in accordance with Section 8.1 of
[RFC8555], represented as a CBOR text string.
An ACME response administrative record would have CBOR diagnostic Administrative Record Content: The Response Bundle administrative
notation (truncated for terseness) as: record content SHALL consist of a CBOR map containing two pairs.
One pair SHALL consist of key 1 with value of ACME challenge
token-part1, copied from the Request Bundle, represented as a CBOR
byte string. One pair SHALL consist of key 2 with value of the
SHA-256 digest [FIPS180-4] of the ACME Key Authorization in
accordance with Section 8.1 of [RFC8555], represented as a CBOR
byte string.
[ An example full Response Bundle is included in Appendix B.2
2, / response indicator /
"qXjSp7npR2YtUyjbhV00DA.9jg46WB3...fm21mqTI" / key authorization /
]
Response Bundles MAY be BIB-signed in accordance with Response Bundles MAY be BIB-signed in accordance with
[I-D.ietf-dtn-bpsec] if the BP agent is capable of signing bundles. [I-D.ietf-dtn-bpsec] if the BP agent is capable of signing bundles.
A BIB on the bundle gives no more security than the Key Authorization A BIB on the bundle gives no more security than the Key Authorization
itself. Response Bundles SHOULD NOT be directly encrypted (by BCB or itself. Response Bundles SHOULD NOT be directly encrypted (by BCB or
any other method). any other method).
4.5. Response Bundle Checks 3.5. 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 expected Key Authorization * The response payload contains the <token-part1> as sent in the
computed by the ACME server. 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-part1> 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. Certificate Request Profile
The ultimate purpose of this ACME validation is to allow a CA to
issue certificates following the profiles of Section 4.4.2 of
[I-D.ietf-dtn-tcpclv4] and [I-D.bsipos-dtn-bpsec-cose]. These
purposes are referred to here as bundle security certificates.
One common behavior of bundle security certificates are the use of
the Extended Key Usage key purpose "id-kp-bundleSecurity". Any CA
implementing the validation method defined in this document SHOULD
also support issuing certificates with the bundle security Extended
Key Usage.
4.1. Multiple Identity Claims
A single bundle security certificate request MAY contain a mixed set
of SAN claims, including combinations of "ip", "dns", and "uri"
claims. There is no restriction on how a certificate combines these
claims, but each claim MUST be validated by an ACME server to issue
such a certificate as part of an associated ACME order. This is no
different than the existing behavior of [RFC8555] but is mentioned
here to make sure that CA policy handles such situations; especially
related to validation failure of an identifier in the presence of
multiple identifiers. The specific use case of
[I-D.ietf-dtn-tcpclv4] allows, 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.
4.2. Generating Encryption-only or Signing-only Bundle Security
Certificates
ACME extensions specified in this document can be used to request
encryption-only or signing-only bundle security certificates.
In order to request signing only S/MIME certificate, the CSR MUST
include the key usage extension with digitalSignature and/or
nonRepudiation bits set and no other bits set.
In order to request encryption only S/MIME certificate, the CSR MUST
include the key usage extension with keyEncipherment or keyAgreement
bits set and no other bits set.
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
server to issue an S/MIME certificate suitable for both signing and
encryption.
5. Implementation Status 5. Implementation Status
[NOTE to the RFC Editor: please remove this section before [NOTE to the RFC Editor: please remove this section before
publication, as well as the reference to [RFC7942] and publication, as well as the reference to [RFC7942] and
[github-acme-dtnnodeid].] [github-acme-dtnnodeid].]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
skipping to change at page 11, line 39 skipping to change at page 14, line 5
as a GitHub project [github-acme-dtnnodeid] and is intended to use as as a GitHub project [github-acme-dtnnodeid] and is intended to use as
a proof-of-concept and as a possible source of interoperability a proof-of-concept and as a possible source of interoperability
testing. This example implementation only constructs encoded bundles testing. This example implementation only constructs encoded bundles
and does not attempt to provide a full BP Agent interface. and does not attempt to provide a full BP Agent interface.
6. Security Considerations 6. Security Considerations
This section separates security considerations into threat categories This section separates security considerations into threat categories
based on guidance of BCP 72 [RFC3552]. based on guidance of BCP 72 [RFC3552].
6.1. Threat: Passive Leak of Bundle Data 6.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 ACME data itself is a random token transferred in plaintext. The ACME data itself is a random token
(nonce) and a cryptographic signature, so there is no sensitive data (nonce) and a cryptographic signature, so there is no sensitive data
to be leaked within the Node ID Validation bundle exchange. to be leaked within the Node ID Validation bundle exchange.
Under certain circumstances, when BPSEC key material is available to Under certain circumstances, when BPSEC key material is available to
the BP agent managed by the ACME client, the use of a BCB for the the BP agent managed by the ACME client, the use of a BCB for the
Request Bundle and/or Response Bundle can give additional Request Bundle and/or Response Bundle can give additional
confidentiality to the bundle metadata. This is not expected to be a confidentiality to the bundle metadata. This is not expected to be a
general use case, as the whole point of ACME is to validate general use case, as the whole point of ACME is to validate
identifiers of untrusted client services. identifiers of untrusted client services.
6.2. Threat: BP Node Impersonation 6.2. Threat: BP Node Impersonation
As described in Section 8.1 of [RFC8555], it is possible for an As described in Section 8.1 of [RFC8555], it is possible for an
active attacker to alter data on both ACME client channel and the DTN active attacker to alter data on both ACME client channel and the DTN
validation channel. validation channel.
One way to mitigate single-path MitM attacks is to attempt validation One way to mitigate single-path on-path attacks is to attempt
of the same Node ID via multiple bundle routing paths, as recommended validation of the same Node ID via multiple bundle routing paths, as
in Section 4. It is not a trivial task to guarantee bundle routing recommended in Section 3. It is not a trivial task to guarantee
though, so more advanced techniques such as onion routing (using bundle routing though, so more advanced techniques such as onion
bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect]) could be routing (using bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect])
employed. could be employed.
Under certain circumstances, when BPSEC key material is available to Under certain circumstances, when BPSEC key material is available to
the BP agent managed by the ACME client, the use of a BIB signature the BP agent managed by the ACME client, the use of a BIB signature
on the Response Bundle can give additional assurance that the on the Response Bundle can give additional assurance that the
response is coming from a valid BP agent. response is coming from a valid BP agent.
6.3. Threat: Denial of Service 6.3. Threat: Denial of Service
The behaviors described in this section all amount to a potential The behaviors described in this section all amount to a potential
denial-of-service to a BP agent. denial-of-service to a BP agent.
skipping to change at page 12, line 40 skipping to change at page 15, line 10
not conform to the specific time interval and challenge token for not conform to the specific time interval and challenge token for
which the ACME client has informed the BP agent that challenges are which the ACME client has informed the BP agent that challenges are
expected. The victim BP agent can require all Challenge Bundles to expected. The victim BP agent can require all Challenge Bundles to
be BIB-signed to ensure authenticity of the challenge. be BIB-signed to ensure authenticity of the challenge.
Similar to other validation methods, an ACME server validating a DTN Similar to other validation methods, an ACME server validating a DTN
Node ID could be used as a denial of service amplifier. For this Node ID could be used as a denial of service amplifier. For this
reason any ACME server can rate-limit validation activities for reason any ACME server can rate-limit validation activities for
individual clients and individual certificate requests. individual clients and individual certificate requests.
6.4. Multiple Certificate Claims
A single certificate request can contain a mixed set of SAN claims,
including combinations of "dns" and "uri" claims. There is no
restriction on how a certificate combines these claims, but each
claim needs to be validated to issue such a certificate as part of an
associated ACME order. This is no different than the existing
behavior of [RFC8555] but is mentioned here to make sure that CA
policy handles such situations; especially related to validation
failure of an identifier in the presence of multiple identifiers.
The specific use case of [I-D.ietf-dtn-tcpclv4] allows, 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.
7. IANA Considerations 7. IANA Considerations
This specification adds to the ACME registry and BP registry for this This specification adds to the ACME registry and BP registry for this
behavior. behavior.
7.1. ACME Identifier Type 7.1. ACME Identifier Type
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry [IANA-ACME], the following entry has been added to Protocol" registry [IANA-ACME], the following entry has been added to
the "ACME Identifier Types" sub-registry. the "ACME Identifier Types" sub-registry.
+=======+====================+ +=======+==================================+
| Label | Reference | | Label | Reference |
+=======+====================+ +=======+==================================+
| uri | This specification | | uri | This specification and [RFC3986] |
+-------+--------------------+ +-------+----------------------------------+
Table 1 Table 1
7.2. ACME Validation Method 7.2. ACME Validation Method
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry [IANA-ACME], the following entry has been added to Protocol" registry [IANA-ACME], the following entry has been added to
the "ACME Validation Methods" sub-registry. the "ACME Validation Methods" sub-registry.
+===============+=================+======+====================+ +===============+=================+======+====================+
skipping to change at page 14, line 14 skipping to change at page 16, line 21
8. Acknowledgments 8. 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 generation.
9. References 9. References
9.1. Normative References 9.1. Normative References
[FIPS180-4]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, August 2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/
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/>.
[IANA-BP] IANA, "Bundle Protocol", [IANA-BP] IANA, "Bundle Protocol",
<https://www.iana.org/assignments/bundle/>. <https://www.iana.org/assignments/bundle/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 15, line 39 skipping to change at page 18, line 8
[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. Birrane, "Bundle Protocol
Version 7", Work in Progress, Internet-Draft, draft-ietf- Version 7", Work in Progress, Internet-Draft, draft-ietf-
dtn-bpbis-26, 28 July 2020, dtn-bpbis-31, 25 January 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-bpbis-26>. <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 Birrane, E. and K. McKeever, "Bundle Protocol Security
Specification", Work in Progress, Internet-Draft, draft- Specification", Work in Progress, Internet-Draft, draft-
ietf-dtn-bpsec-22, 10 March 2020, ietf-dtn-bpsec-26, 8 January 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-bpsec-22>. <https://tools.ietf.org/html/draft-ietf-dtn-bpsec-26>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-acme-email-smime] [I-D.ietf-acme-email-smime]
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",
Work in Progress, Internet-Draft, draft-ietf-acme-email- Work in Progress, Internet-Draft, draft-ietf-acme-email-
smime-08, 16 June 2020, <https://tools.ietf.org/html/ smime-13, 20 November 2020, <https://tools.ietf.org/html/
draft-ietf-acme-email-smime-08>. 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-21, 12 June 2020, tcpclv4-24, 7 December 2020,
<https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-21>. <https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-24>.
[I-D.bsipos-dtn-bpsec-cose]
Sipos, B., "DTN Bundle Protocol Security COSE Security
Contexts", Work in Progress, Internet-Draft, draft-bsipos-
dtn-bpsec-cose-04, 22 December 2020,
<https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose-
04>.
[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 "TBD" 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 /= [TBD, acme-record] $admin-record /= [0xFFFF, acme-record]
acme-record = $acme-record .within acme-record-structure acme-record = {
acme-record-structure = [ token-part1,
type-code: uint, ? key-auth-digest ; present for Response Bundles
acme-content: tstr }
] token-part1 = (1 => bstr)
; The type code distinguishes the purpose key-auth-digest = (2 => bstr)
$acme-record /= [
1,
token-part1: tstr
]
$acme-record /= [
2,
key-authorization: tstr
]
Appendix B. Example Bundles Appendix B. Example Bundles
The provided figures are extended diagnostic notation [RFC8610]. [NOTE to the RFC Editor: The "0xFFFF" in these examples are replaced
These examples use a placeholder administrative record type code of by the "ACME Node ID Validation" administrative record type code.]
0xFFFF in order to be valid CBOR encoding. The examples also use no
block CRC or integrity block, which is for simplicity and is not This example is a bundle exchange for the ACME server with Node ID
recommended for normal use. "dtn://acme-server/" performing a verification for ACME client Node
ID "dtn://acme-client/". The example bundles use no block CRC or
BPSec integrity, which is for simplicity and is not recommended for
normal use. The provided figures are extended diagnostic notation
[RFC8610].
For this example the ACME client key thumbprint has the base64url
encoded value of:
"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
And the ACME-server generated token-part2 (transported to the ACME
client via HTTPS) has the base64url-encoded value of:
"tPUZNY4ONIk6LxErRFEjVw"
B.1. Challenge Bundle B.1. Challenge Bundle
An example of a Challenge Bundle sent to "dtn://acme-client/" is: For the single challenge bundle in this example, the token-part1
(transported as byte string via BP) has the base64url-encoded value
of:
"p3yRYFU4KxwQaHQjJ2RdiQ"
The minimal-but-valid Challenge Bundle is shown in Figure 1. This
challenge requires that the ACME client respond within a 60 second
time window.
[ [
[ [
7, / BP version / 7, / BP version /
0x000002, / flags: payload-is-an-administrative-record / 0x22, / flags: user-app-ack, payload-is-an-admin-record /
0, / CRC type / 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, "//acme-server/"], / report-to /
[0, 40], / timestamp / [1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 /
1000000 / lifetime / 60000 / lifetime: 60s /
], ],
[ [
1, / block type code / 1, / block type code /
1, / block number / 1, / block number /
0, / flags / 0, / flags /
0, / CRC type / 0, / CRC type: none /
<<[ / type-specific data / <<[ / type-specific data /
0xFFFF, / record-type-code / 0xFFFF, / record-type-code /
[ / record-content / { / record-content /
1, / challenge indicator / 1: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-part1 /
"LVMo24VdNAw" / token-part1 / }
]
]>> ]>>
] ]
] ]
Figure 1: Example Challenge Bundle
B.2. Response Bundle B.2. Response Bundle
An example of a Response Bundle sent to "dtn://acme-server/" is: When the tokens are combined with the key fingerprint, the full Key
Authorization value (a single string split across lines for
readability) is:
[ "p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw.LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
[
7, / BP version / The minimal-but-valid Response Bundle is shown in Figure 2. This
0x000002, / flags: payload-is-an-administrative-record / response indicates that there is 30 seconds remaining in the response
0, / CRC type / time window.
[1, "//acme-server/"], / destination /
[1, "//acme-client/"], / source / [
[1, "//acme-client/"], / report-to / [
[0, 40], / timestamp / 7, / BP version /
1000000 / lifetime / 0x02, / flags: payload-is-an-admin-record /
], 0, / CRC type: none /
[ [1, "//acme-server/"], / destination /
1, / block type code / [1, "//acme-client/"], / source /
1, / block number / [1, 0], / report-to: none /
0, / flags / [1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 /
0, / CRC type / 30000 / lifetime: 30s /
<<[ / type-specific data / ],
0xFFFF, / record-type-code / [
[ / record-content / 1, / block type code /
2, / response indicator / 1, / block number /
"qXjSp7npR2YtUyjbhV00DA.9jg46WB3...fm21mqTI" / key authorization / 0, / flags /
] 0, / CRC type: none /
]>> <<[ / type-specific data /
] 0xFFFF, / record-type-code /
] { / record-content /
1: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-part1 /
2: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew' / key auth. digest /
}
]>>
]
]
Figure 2: 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. 79 change blocks. 
232 lines changed or deleted 346 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/