draft-ietf-acme-dtnnodeid-06.txt   draft-ietf-acme-dtnnodeid-07.txt 
Automated Certificate Management Environment B. Sipos Automated Certificate Management Environment B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Intended status: Experimental 13 October 2021 Intended status: Experimental 14 November 2021
Expires: 16 April 2022 Expires: 18 May 2022
Automated Certificate Management Environment (ACME) Delay-Tolerant Automated Certificate Management Environment (ACME) Delay-Tolerant
Networking (DTN) Node ID Validation Extension Networking (DTN) Node ID Validation Extension
draft-ietf-acme-dtnnodeid-06 draft-ietf-acme-dtnnodeid-07
Abstract Abstract
This document specifies an extension to the Automated Certificate This document specifies an extension to the Automated Certificate
Management Environment (ACME) protocol which allows an ACME server to Management Environment (ACME) protocol which allows an ACME server to
validate the Delay-Tolerant Networking (DTN) Node ID for an ACME validate the Delay-Tolerant Networking (DTN) Node ID for an ACME
client. The DTN Node ID is encoded as a certificate Subject client. The DTN Node ID is encoded as a certificate Subject
Alternative Name (SAN) of type otherName with a name form of Alternative Name (SAN) of type otherName with a name form of
BundleEID and as an ACME Identifier type "bundleEID". BundleEID and as an ACME Identifier type "bundleEID".
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 16 April 2022. This Internet-Draft will expire on 18 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 8, line 47 skipping to change at page 8, line 47
server validates control of the Node ID by verifying that received server validates control of the Node ID by verifying that received
Response Bundles correspond with the BP Node and client account key Response Bundles correspond with the BP Node and client account key
being validated. being validated.
Similar to the ACME use case for validating email address ownership Similar to the ACME use case for validating email address ownership
[RFC8823], this challenge splits the token into several parts, each [RFC8823], this challenge splits the token into several parts, each
being transported by a different channel, and the Key Authorization being transported by a different channel, and the Key Authorization
result requires combining all parts of the token. The token parts result requires combining all parts of the token. The token parts
are: are:
token-chal This token is unique to, and identifies, each ACME token-chal: This token is unique to, and identifies, each ACME
authorization. It is contained in the Challenge Object of authorization. It is contained in the Challenge Object of
Section 3.1 as well as the Challenge Bundle of Section 3.3 and Section 3.1 as well as the Challenge Bundle of Section 3.3 and
Response Bundle of Section 3.4. Each authorization can consist of Response Bundle of Section 3.4. Each authorization can consist of
multiple Challenge Bundles (e.g. taking different routes), but multiple Challenge Bundles (e.g. taking different routes), but
they all share the same token-chal value. This ensures that the they all share the same token-chal value. This ensures that the
Key Authorization is bound to the specific ACME challenge (and Key Authorization is bound to the specific ACME challenge (and
parent ACME authorization) and also allows the ACME client's BP parent ACME authorization) and also allows the ACME client's BP
agent to filter-in only valid Challenge Bundles. This token is agent to filter-in only valid Challenge Bundles. This token is
also accessible to DTN on-path eavesdroppers. also accessible to DTN on-path eavesdroppers.
token-bundle This token is unique to each Challenge Bundle sent by token-bundle: This token is unique to each Challenge Bundle sent by
the ACME server. It is contained in the Challenge Bundle of the ACME server. It is contained in the Challenge Bundle of
Section 3.3 and Response Bundle of Section 3.4. This ensures that Section 3.3 and Response Bundle of Section 3.4. This ensures that
the Key Authorization is bound to the ability to receive the the Key Authorization is bound to the ability to receive the
Challenge Bundle and not just have access to the ACME Challenge Challenge Bundle and not just have access to the ACME Challenge
Object. This token is also accessible to DTN on-path Object. This token is also accessible to DTN on-path
eavesdroppers. eavesdroppers.
For each ACME server, the pair of token-chal and token-bundle values For each ACME server, the pair of token-chal and token-bundle values
is the unique correlator between Challenge and Response bundles. is the unique correlator between Challenge and Response bundles.
Because multiple Challenge Bundles can be sent to validate the same Because multiple Challenge Bundles can be sent to validate the same
skipping to change at page 11, line 39 skipping to change at page 11, line 39
source (required, array of string): An unordered list of possible source (required, array of string): An unordered list of possible
source Node ID of bundles originating at the BP agent(s) of the source Node ID of bundles originating at the BP agent(s) of the
ACME server. See Section 3.5 for a discussion of multi- ACME server. See Section 3.5 for a discussion of multi-
perspective validation using multiple sources. The array SHALL be perspective validation using multiple sources. The array SHALL be
non-empty. The array MAY contain Node IDs which are not actually non-empty. The array MAY contain Node IDs which are not actually
used as a challenge bundle source. used as a challenge bundle source.
token-chal (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 contain any characters outside the base64url of entropy. It MUST NOT contain any characters outside the
alphabet as described in Section 5 of [RFC4648]. Trailing '=' base64url alphabet as described in Section 5 of [RFC4648].
padding characters MUST be stripped. See [RFC4086] for additional Trailing '=' padding characters MUST be stripped. See [RFC4086]
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://acme-server/"], "source": ["dtn://acme-server/"],
"token-chal": "tPUZNY4ONIk6LxErRFEjVw" "token-chal": "tPUZNY4ONIk6LxErRFEjVw"
} }
The token-chal value included in this object is fixed for the entire The token-chal value included in this object is fixed for the entire
challenge, and may correspond with multiple separate token-bundle challenge, and may correspond with multiple separate token-bundle
values when multiple Challenge Bundles are sent for a single values when multiple Challenge Bundles are sent for a single
skipping to change at page 22, line 22 skipping to change at page 22, line 22
This specification adds to the ACME registry and BP registry for this This specification adds to the ACME registry and BP registry for this
behavior. behavior.
8.1. ACME Identifier Types 8.1. ACME Identifier Types
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry [IANA-ACME], the following entry has been added to Protocol" registry [IANA-ACME], the following entry has been added to
the "ACME Identifier Types" sub-registry. the "ACME Identifier Types" sub-registry.
+=======+==================================+ +===========+==================================+
| Label | Reference | | Label | Reference |
+=======+==================================+ +===========+==================================+
| uri | This specification and [RFC3986] | | bundleEID | This specification and [RFC3986] |
+-------+----------------------------------+ +-----------+----------------------------------+
Table 1 Table 1
8.2. ACME Validation Methods 8.2. ACME Validation Methods
Within the "Automated Certificate Management Environment (ACME) Within the "Automated Certificate Management Environment (ACME)
Protocol" registry [IANA-ACME], the following entry has been added to Protocol" registry [IANA-ACME], the following entry has been added to
the "ACME Validation Methods" sub-registry. the "ACME Validation Methods" sub-registry.
+===============+=================+======+====================+ +===============+=================+======+====================+
| Label | Identifier Type | ACME | Reference | | Label | Identifier Type | ACME | Reference |
+===============+=================+======+====================+ +===============+=================+======+====================+
| dtn-nodeid-01 | uri | Y | This specification | | dtn-nodeid-01 | bundleEID | Y | This specification |
+---------------+-----------------+------+--------------------+ +---------------+-----------------+------+--------------------+
Table 2 Table 2
8.3. Bundle Administrative Record Types 8.3. Bundle Administrative Record Types
Within the "Bundle Protocol" registry [IANA-BP], the following Within the "Bundle Protocol" registry [IANA-BP], the following
entries have been added to the "Bundle Administrative Record Types" entries have been added to the "Bundle Administrative Record Types"
sub-registry. sub-registry.
skipping to change at page 28, line 8 skipping to change at page 28, line 8
For the single challenge bundle in this example, the token-bundle 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 2. 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 /
[1, "//acme-server/"], / report-to / [1, "//acme-server/"], / report-to /
[1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 / [1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 /
60000 / lifetime: 60s / 60000 / lifetime: 60s /
], ],
skipping to change at page 29, line 5 skipping to change at page 29, line 5
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 3. 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 /
[1, 0], / report-to: none / [1, 0], / report-to: none /
[1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 / [1030000, 0], / timestamp: 2000-01-01T00:17:10+00:00 /
30000 / lifetime: 30s / 30000 / lifetime: 30s /
], ],
 End of changes. 10 change blocks. 
18 lines changed or deleted 18 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/