draft-ietf-acme-dtnnodeid-01.txt   draft-ietf-acme-dtnnodeid-02.txt 
Automated Certificate Management Environment B. Sipos Automated Certificate Management Environment B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Intended status: Experimental 7 March 2021 Intended status: Experimental 16 April 2021
Expires: 8 September 2021 Expires: 18 October 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-01 draft-ietf-acme-dtnnodeid-02
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 8 September 2021. This Internet-Draft will expire on 18 October 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. Authorization Strategy . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Authorization Strategy . . . . . . . . . . . . . . . . . 4
1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 5
2. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. URI ACME Identifier . . . . . . . . . . . . . . . . . . . . . 6
3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 6 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 6
3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 8 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 9
3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 9 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 9
3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 9 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 10
3.4. ACME Node ID Validation Response Bundles . . . . . . . . 10 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 11
3.5. Response Bundle Checks . . . . . . . . . . . . . . . . . 11 3.5. Response Bundle Checks . . . . . . . . . . . . . . . . . 12
4. Certificate Request Profile . . . . . . . . . . . . . . . . . 12 4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 13
4.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 12 5. Certificate Request Profile . . . . . . . . . . . . . . . . . 14
4.2. Generating Encryption-only or Signing-only Bundle Security 5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 14
Certificates . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Generating Encryption-only or Signing-only Bundle Security
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 Certificates . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
6.1. Threat: Passive Leak of Validation Data . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 14 7.1. Threat: Passive Leak of Validation Data . . . . . . . . . 15
6.3. Threat: Denial of Service . . . . . . . . . . . . . . . . 14 7.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 16
7.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 15 7.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 17
7.2. ACME Validation Method . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.3. BP Bundle Administrative Record Types . . . . . . . . . . 15 8.1. ACME Identifier Type . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. ACME Validation Method . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.3. BP Bundle Administrative Record Types . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Administrative Record Types CDDL . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
Appendix B. Example Bundles . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 20
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 21
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Example Bundles . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 22
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
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
Subject Alternative Name (SAN) of type Uniform Resource Identifier Subject Alternative Name (SAN) of type Uniform Resource Identifier
(URI) used to represent the Node ID of a Delay-Tolerant Networking (URI) used to represent the Node ID of a Delay-Tolerant Networking
(DTN) Node. A DTN Node ID is a URI with a specific set of allowed (DTN) Node. A DTN Node ID is a URI with a specific set of allowed
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 (CSR). Because a single order
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 4.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 BP agent with the new certificate is an implementation configures the Bundle Protocol (BP) agent with the new certificate is
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 [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. Scope
This document describes the ACME messages, BPv7 payloads, and BPSec
requirements needed to validate Node ID ownership. This document
does not address:
* Specific BP extension blocks or BPSec security contexts necessary
to fulfill the security requirements of this protocol. The exact
security context needed, and their parameters, are network-
specific.
* Policies or mechanisms for defining or configuring bundle
integrity gateways, or trusting integrity gateways on an
individual entity or across a network.
* Mechanisms for locating or identifying other bundle entities
(peers) within a network or across an internet. The mapping of
Node ID to potential convergence layer (CL) protocol and network
address is left to implementation and configuration of the BP
Agent and its various potential routing strategies.
* Logic for routing bundles along a path toward a bundle's endpoint.
This protocol is involved only in creating bundles at a source and
handling them at a destination.
* Logic for performing rate control and congestion control of bundle
transfers. The ACME server is responsible for rate control of
validation requests.
* Policies or mechanisms for provisioning, deploying, or accessing
certificates and private keys; deploying or accessing certificate
revocation lists (CRLs); or configuring security parameters on an
individual entity or across a network.
* Policies or mechanisms for an ACME server to handle mixed-use
certificate requests. This specification is focused only on
single-use DTN-specific PKIX profiles.
1.2. 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. An Endpoint ID is used as the destination of accompanying metadata. An Endpoint ID is used as the destination of
a Bundle and can indicate both a unicast or a multicast destination. a Bundle and can indicate both a unicast or a multicast destination.
A Node ID is used to identify the source of a Bundle and is used for A Node ID is used to identify the source of a Bundle and is used for
routing through intermediate nodes, including the final node(s) used routing through intermediate nodes, including the final node(s) used
to deliver a Bundle to its destination endpoint. A Node ID can also to deliver a Bundle to its destination endpoint. A Node ID can also
be used as an endpoint for administrative bundles. More detailed be used as an endpoint for administrative bundles. More detailed
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" which could be used as a DTN Node ID, 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 signature, and sends an ACME the Challenge Bundle, generates an ACME key authorization digest, and
Node ID Validation Response Bundle with the signature. Finally, the sends an ACME Node ID Validation Response Bundle in reply. Finally,
ACME server receives the Response Bundle and checks that the the ACME server receives the Response Bundle and checks that the
signature came from the client account key associated with the digest was generated for the associated ACME challenge and from the
original request. client account key associated with the 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.
1.2. Terminology 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
1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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 5, line 5 skipping to change at page 6, 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.
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 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 3), 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" in certificate requests MUST appear in an
attribute [RFC2985] requesting a subjectAltName extension of type extensionRequest attribute [RFC2985] containing a subjectAltName
uniformResourceIdentifier having a value consistent with the extension of type uniformResourceIdentifier having a value consistent
requirements of [RFC3986]. with the requirements of [RFC3986]. Because the
uniformResourceIdentifier is encoded as an IA5String it SHALL be
treated as being in the percent-encoded form of Section 2.1 of
[RFC3986]. Any "uri" identifier which fails to properly percent-
decode SHALL be rejected with an ACME error type of "malformed".
Any identifier of type "uri" in a newOrder request MUST NOT have a Identifiers of type "uri" present in ACME messages are unicode text
wildcard ("*") character in its value. strings and SHALL NOT be percent encoded.
If an ACME server wishes to request proof that a user controls a URI, The ACME server SHALL decode and normalize (based on scheme-specific
it SHALL create an authorization with the identifier type "uri". The syntax) all received identifiers of type "uri". Any "uri" identifier
value field of the identifier SHALL contain the textual form of the request which uses a scheme not handled by the ACME server or for
URI as defined in Section 3 of [RFC3986]. The ACME server SHALL NOT which the URI does not match the scheme-specific syntax SHALL be
decode or attempt to dereference the URI value on its own. It is the rejected with an ACME error type of "rejectedIdentifier".
responsibility of a validation method to ensure the URI ownership via
scheme-specific means authorized by the ACME client. When an ACME server needs to request proof that a client controls a
URI, it SHALL create an authorization with the identifier type "uri".
The ACME server SHALL NOT attempt to dereference the URI value on its
own. It is the responsibility of a validation method to ensure the
URI ownership via scheme-specific means authorized by the ACME
client.
An identifier for the Node ID of "dtn://example/" would be formatted An identifier for the Node ID of "dtn://example/" would be formatted
as: as:
{"type": "uri", "value": "dtn://example/"} {"type": "uri", "value": "dtn://example/"}
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
skipping to change at page 6, line 41 skipping to change at page 7, line 32
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. part2> from the challenge object in accordance with Section 3.1.
3. The ACME client indicates to the BP agent the source and 3. The ACME client indicates to the BP agent the source Node ID and
challenge <token-part2> which is authorized for use. challenge <token-part2> which is authorized for use and the
associated client account key fingerprint.
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 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.
6. The ACME client concatenates <token-part1> with <token-part2> (as 6. The ACME client concatenates <token-part1> with <token-part2> (as
text strings) and computes the Key Authorization in accordance text strings) and computes the Key Authorization in accordance
with Section 8.1 of [RFC8555] using the full token and client with Section 8.1 of [RFC8555] using the full token and client
account key digest. account key fingerprint.
7. The ACME client indicates to the BP agent the SHA-256 digest of 7. The ACME client indicates to the BP agent the SHA-256 digest of
the Key Authorization result, which results in a Response Bundle the Key Authorization result, which results in a Response Bundle
being sent back to the ACME server in accordance with being sent back 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
skipping to change at page 9, line 4 skipping to change at page 9, line 38
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://example-acme-server/",
"token-part2": "tPUZNY4ONIk6LxErRFEjVw" "token-part2": "tPUZNY4ONIk6LxErRFEjVw"
} }
The only over-the-wire data required by ACME for a Challenge Bundle
is a nonce token, split into two parts, but the response data needs a The <token-part2> value included in this object is fixed for the
client account key to generate the Key Authorization and its digest. entire challenge, and may correspond with multiple separate <token-
The client account key is kept within the ACME client, the BP agent part1> values when multiple Challenge Bundles are sent for a single
needs only the derived key thumbprint for its Response Bundle. 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 9, line 43 skipping to change at page 10, line 29
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.
3.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 Each ACME Node ID Validation Challenge Bundle SHALL be
listed here: structured and encoded in accordance with [I-D.ietf-dtn-bpbis].
Each Challenge Bundle has parameters as listed here:
Bundle Processing Control Flags: The primary block flags SHALL Bundle Processing Control Flags: The primary block flags SHALL
indicate that the payload is an administrative record. The indicate that the payload is an administrative record. The
primary block flags SHALL indicate that user application primary block flags SHALL indicate that user application
acknowledgement is requested; this flag distinguishes the acknowledgement is requested; this flag distinguishes the
Challenge Bundle from the Response Bundle. The primary block Challenge Bundle from the Response Bundle. The primary block
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
skipping to change at page 10, line 28 skipping to change at page 11, line 11
Report-to Node ID: The Report-to Node ID SHALL indicate the Node ID 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 of the ACME server performing the challenge if status reports are
requested. 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 7.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 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 * 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
bundle. This value MUST have at least 128 bits of entropy.
See [RFC4086] for additional information on randomness
requirements.
Challenge Bundles SHOULD be BIB-signed in accordance with This structure is part of the extension CDDL in Appendix A. An
[I-D.ietf-dtn-bpsec] if the ACME server is capable of signing example full Challenge Bundle is included in Appendix B.1
bundles. BP agents SHALL refuse to respond to a Challenge Bundle
which is signed by a known ACME server but has an invalid signature. Challenge Bundles SHALL include a Block Integrity Block (BIB) in
Challenge Bundles SHOULD NOT be directly encrypted (by BCB or any accordance with Section 4. An ACME client BP agent SHALL NOT respond
other method). to a Challenge Bundle which does not have a BIB-covered payload. An
ACME client BP agent SHALL NOT respond to a Challenge Bundle with a
BIB which has a security source which is untrusted or has signature
which fails to verify.
Challenge Bundles SHALL NOT be directly encrypted by Block
Confidentiality Block (BCB) or any other method (see Section 7.1).
3.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 Each ACME Node ID Validation Response Bundle SHALL be structured
here: and encoded in accordance with [I-D.ietf-dtn-bpbis].
Each Response Bundle has parameters as listed here:
Bundle Processing Control Flags: The primary block flags SHALL Bundle Processing Control Flags: The primary block flags SHALL
indicate that the payload is an administrative record. The indicate that the payload is an administrative record. The
primary block flags SHALL NOT indicate that user application primary block flags SHALL NOT indicate that user application
acknowledgement is requested; this flag distinguishes the Response acknowledgement is requested; this flag distinguishes the Response
Bundle from the Challenge Bundle. The primary block flags MAY Bundle from the Challenge Bundle. The primary block flags MAY
indicate that status reports are requested; such status can be indicate that status reports are requested; such status can be
helpful to troubleshoot routing issues. 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
skipping to change at page 11, line 27 skipping to change at page 12, line 17
Source Node ID: The Source Node ID SHALL be identical to the the Source Node ID: The Source Node ID SHALL be identical to the the
Destination EID of the Challenge Bundle to which this response Destination EID of the Challenge Bundle to which this response
corresponds. corresponds.
Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set
to the time at which the response was generated. The response to the time at which the response was generated. The response
Lifetime SHALL indicate the response interval remaining if the Lifetime SHALL indicate the response interval remaining if the
Challenge Bundle indicated a limited Lifetime. Challenge Bundle indicated a limited Lifetime.
Administrative Record Type Code: Set to the ACME Node ID Validation Administrative Record Type Code: Set to the ACME Node ID Validation
type code defined in Section 7.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 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 * 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.
Response Bundles MAY be BIB-signed in accordance with * One pair SHALL consist of key 2 with value of the SHA-256
[I-D.ietf-dtn-bpsec] if the BP agent is capable of signing bundles. digest [FIPS180-4] of the ACME Key Authorization in accordance
A BIB on the bundle gives no more security than the Key Authorization with Section 8.1 of [RFC8555], represented as a CBOR byte
itself. Response Bundles SHOULD NOT be directly encrypted (by BCB or string.
any other method).
This structure is part of the extension CDDL in Appendix A. An
example full Response Bundle is included in Appendix B.2
Response Bundles SHOULD include a BIB in accordance with Section 4.
An ACME server BP agent SHOULD NOT accept a Response Bundle which
does not have a BIB-covered payload. An ACME server BP agent SHALL
NOT accept a Response Bundle Bundle with a BIB which has a security
source which is untrusted or has signature which fails to verify.
Response Bundles SHALL NOT be directly encrypted by BCB or any other
method (see Section 7.1 for explanation).
3.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
skipping to change at page 12, line 21 skipping to change at page 13, line 21
Challenge Bundle. The response payload contains the expected Key Challenge Bundle. The response payload contains the expected Key
Authorization digest computed by the ACME server. Because Authorization digest computed by the ACME server. Because
multiple Challenge Bundles can be sent to validate the same Node multiple Challenge Bundles can be sent to validate the same Node
ID, the <token-part1> in the response is needed to correlate with ID, the <token-part1> in the response is needed to correlate with
the expected Key Authorization digest. 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 4. Bundle Integrity Gateway
This section defines a BIB use which closely resembles the function
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
BIB before forwarding it. The bundle receiver then need not trust
the source of the bundle, but only trust this security source node.
The receiver needs policy configuration to know which security source
is permitted to vouch for which bundle sources.
An integrity gateway SHALL validate the Source Node ID of a bundle,
using local-network-specific means, before adding a BIB to the
bundle. The exact means by which an integrity gateway validates a
bundle's source is network-specific, but could use physical-layer,
network-layer or BP-convergence-layer authentication. The bundle
source could also add its own BIB with a local-network-specific
security context or local-network-specific key material (i.e. a group
key shared within the local network).
When an integrity gateway adds a BIB it SHALL be in accordance with
[I-D.ietf-dtn-bpsec]. The BIB targets SHALL cover both the payload
block and the primary block (either directly as a target or as
additional authenticated data for the payload block signature). The
Security Source of this BIB SHALL be either the bundle source Node ID
itself or a routing node trusted by the destination node (see
Section 7.2).
5. Certificate Request Profile
The ultimate purpose of this ACME validation is to allow a CA to The ultimate purpose of this ACME validation is to allow a CA to
issue certificates following the profiles of Section 4.4.2 of issue certificates following the profiles of Section 4.4.2 of
[I-D.ietf-dtn-tcpclv4] and [I-D.bsipos-dtn-bpsec-cose]. These [I-D.ietf-dtn-tcpclv4], [I-D.sipos-dtn-udpcl], and
purposes are referred to here as bundle security certificates. [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 One defining aspect of bundle security certificates is the Extended
the Extended Key Usage key purpose "id-kp-bundleSecurity". Any CA Key Usage key purpose "id-kp-bundleSecurity" of [IANA-SMI]. When
implementing the validation method defined in this document SHOULD requesting a certificate which includes a Node ID SAN, the CSR SHOULD
also support issuing certificates with the bundle security Extended include an Extended Key Usage of id-kp-bundleSecurity. When a bundle
Key Usage. security certificate is issued based on a validated Node ID SAN, the
certificate SHALL include an Extended Key Usage of id-kp-
bundleSecurity.
4.1. Multiple Identity Claims 5.1. Multiple Identity Claims
A single bundle security certificate request MAY contain a mixed set A single bundle security CSR MAY contain a mixed set of SAN claims,
of SAN claims, including combinations of "ip", "dns", and "uri" including combinations of "ip", "dns", and "uri" claims. There is no
claims. There is no restriction on how a certificate combines these restriction on how a certificate combines these claims, but each
claims, but each claim MUST be validated by an ACME server to issue claim MUST be validated by an ACME server to issue such a certificate
such a certificate as part of an associated ACME order. This is no as part of an associated ACME order. This is no different than the
different than the existing behavior of [RFC8555] but is mentioned existing behavior of [RFC8555] but is mentioned here to make sure
here to make sure that CA policy handles such situations; especially that CA policy handles such situations; especially related to
related to validation failure of an identifier in the presence of validation failure of an identifier in the presence of multiple
multiple identifiers. The specific use case of identifiers. The specific use case of [I-D.ietf-dtn-tcpclv4] allows,
[I-D.ietf-dtn-tcpclv4] allows, and for some network policies and for some network policies requires, that a certificate
requires, that a certificate authenticate both the DNS name of an authenticate both the DNS name of an entity as well as the Node ID of
entity as well as the Node ID of the entity. the entity.
4.2. Generating Encryption-only or Signing-only Bundle Security 5.2. Generating Encryption-only or Signing-only Bundle Security
Certificates Certificates
ACME extensions specified in this document can be used to request ACME extensions specified in this document can be used to request
encryption-only or signing-only bundle security certificates. encryption-only or signing-only bundle security certificates.
In order to request signing only S/MIME certificate, the CSR MUST In order to request signing only bundle security certificate, the CSR
include the key usage extension with digitalSignature and/or MUST include the key usage extension with digitalSignature and/or
nonRepudiation bits set and no other bits set. nonRepudiation bits set and no other bits set.
In order to request encryption only S/MIME certificate, the CSR MUST In order to request encryption only bundle security certificate, the
include the key usage extension with keyEncipherment or keyAgreement CSR MUST include the key usage extension with keyEncipherment or
bits set and no other bits set. keyAgreement bits set and no other bits set.
Presence of both of the above sets of key usage bits in the CSR, as Presence of both of the above sets of key usage bits in the CSR, as
well as absence of key usage extension in the CSR, signals to ACME well as absence of key usage extension in the CSR, signals to ACME
server to issue an S/MIME certificate suitable for both signing and server to issue a bundle security certificate suitable for both
encryption. signing and encryption.
5. Implementation Status 6. 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
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
skipping to change at page 13, line 49 skipping to change at page 15, line 35
be construed to be, a catalog of available implementations or their be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations can features. Readers are advised to note that other implementations can
exist. exist.
An example implementation of the this draft of ACME has been created An example implementation of the this draft of ACME has been created
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 7. 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 Validation Data 7.1. Threat: Passive Leak of Validation Data
Because this challenge mechanism is used to bootstrap security Because this challenge mechanism is used to bootstrap security
between DTN Nodes, the challenge and its response are likely to be between DTN Nodes, the challenge and its response are likely to be
transferred in plaintext. The ACME data itself is a random token transferred in plaintext. The only ACME data present on-the-wire is
(nonce) and a cryptographic signature, so there is no sensitive data a random token and a cryptographic digest, so there is no sensitive
to be leaked within the Node ID Validation bundle exchange. data to be leaked within the Node ID Validation bundle exchange.
Because each challenge uses a separate token, there is no value in an
on-path attacker seeing the tokens from past challenges and/or
responses.
Under certain circumstances, when BPSEC key material is available to It is possible for intermediate BP nodes to encapsulate-and-encrypt
the BP agent managed by the ACME client, the use of a BCB for the Challenge and/or Response Bundles while they traverse untrusted
Request Bundle and/or Response Bundle can give additional networks, but that is a DTN configuration matter outside of the scope
confidentiality to the bundle metadata. This is not expected to be a of this document.
general use case, as the whole point of ACME is to validate
identifiers of untrusted client services.
6.2. Threat: BP Node Impersonation 7.2. Threat: BP Node Impersonation
As described in Section 8.1 of [RFC8555], it is possible for an As described in Section 8.1 of [RFC8555], it is possible for an
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 on-path attacks is to attempt The primary mitigation is to delegate bundle integrity sourcing to a
trusted routing node near, in the sense of bundle routing topology,
to the bundle source node as defined in Section 4. This is
functionally similar to DKIM signing of [RFC6376] and provides some
level of bundle origination.
Another way to mitigate single-path on-path attacks is to attempt
validation of the same Node ID via multiple bundle routing paths, as validation of the same Node ID via multiple bundle routing paths, as
recommended in Section 3. It is not a trivial task to guarantee recommended in Section 3. It is not a trivial task to guarantee
bundle routing though, so more advanced techniques such as onion bundle routing though, so more advanced techniques such as onion
routing (using bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect]) routing (using bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect])
could be employed. could be employed.
Under certain circumstances, when BPSEC key material is available to 7.3. Threat: Bundle Replay
the BP agent managed by the ACME client, the use of a BIB signature
on the Response Bundle can give additional assurance that the
response is coming from a valid BP agent.
6.3. Threat: Denial of Service It is possible for an on-path attacker to replay both Challenge
Bundles or Response Bundles. Even in a properly-configured DTN it is
possible that intermediate bundle routers to use multicast forwarding
of a unicast-destination bundle.
Ultimately, the point of the ACME bundle exchange is to derive a Key
Authorization and its cryptographic digest and communicate it back to
the ACME server for validation, so the uniqueness of the Key
Authorization directly determines the scope of replay validity. The
uniqueness of each <token-part1> to each challenge bundle ensures
that the Key Authorization is unique to the challenge bundle. The
uniqueness of each <token-part2> to the ACME challenge ensures that
the Key Authorization is unique to that ACME challenge.
Having each bundle's primary block and payload block covered by a BIB
from a trusted security source (see Section 4) ensures that a
replayed bundle cannot be altered in the blocks used by ACME. All
together, these properties mean that there is no degraded security
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
a BIB. The worst that can come of bundle replay is the waste of
network resources as described in Section 7.4.
7.4. Threat: Denial of Service
The behaviors described in this section all amount to a potential The behaviors described in this section all amount to a potential
denial-of-service to a BP agent. denial-of-service to a BP agent.
A malicious entity can continually send ACME Node ID challenges to a A malicious entity can continually send Challenge Bundles to a BP
BP agent. The victim BP agent can ignore ACME challenges which do agent. The victim BP agent can ignore Challenge Bundles which do not
not conform to the specific time interval and challenge token for conform to the specific time interval and challenge token for which
which the ACME client has informed the BP agent that challenges are the ACME client has informed the BP agent that challenges are
expected. The victim BP agent can require all Challenge Bundles to expected. The victim BP agent can require all Challenge Bundles to
be BIB-signed to ensure authenticity of the challenge. be BIB-signed to ensure authenticity of the challenge.
A malicious entity can continually send Response Bundles to a BP
agent. The victim BP agent can ignore Response Bundles which do not
conform to the specific time interval or Source Node ID or challenge
token for an active Node ID validation.
Similar to other validation methods, an ACME server validating a DTN Similar to other validation methods, an ACME server validating a DTN
Node ID could be used as a denial of service amplifier. For this Node ID could be used as a denial of service amplifier. For this
reason any ACME server can rate-limit validation activities for reason any ACME server can rate-limit validation activities for
individual clients and individual certificate requests. individual clients and individual certificate requests.
7. IANA Considerations 8. 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 8.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 and [RFC3986] | | uri | This specification and [RFC3986] |
+-------+----------------------------------+ +-------+----------------------------------+
Table 1 Table 1
7.2. ACME Validation Method 8.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.
+===============+=================+======+====================+ +===============+=================+======+====================+
| Label | Identifier Type | ACME | Reference | | Label | Identifier Type | ACME | Reference |
+===============+=================+======+====================+ +===============+=================+======+====================+
| dtn-nodeid-01 | uri | Y | This specification | | dtn-nodeid-01 | uri | Y | This specification |
+---------------+-----------------+------+--------------------+ +---------------+-----------------+------+--------------------+
Table 2 Table 2
7.3. BP Bundle Administrative Record Types 8.3. BP Bundle Administrative Record Types
Within the "Bundle Protocol" registry [IANA-BP], the following entry Within the "Bundle Protocol" registry [IANA-BP], the following entry
has been added to the "Bundle Administrative Record Types" sub- has been added to the "Bundle Administrative Record Types" sub-
registry. [NOTE to the RFC Editor: For RFC5050 compatibility this registry. [NOTE to the RFC Editor: For RFC5050 compatibility this
value needs to be no larger than 15, but such compatibility is not value needs to be no larger than 15, but such compatibility is not
needed. BPbis has no upper limit on this code point value.] needed. BPbis has no upper limit on this code point value.]
+=======+=========================+====================+
| Value | Description | Reference | +=========================+=======+==============+===============+
+=======+=========================+====================+ | Bundle Protocol Version | Value | Description | Reference |
| TBD | ACME Node ID Validation | This specification | +=========================+=======+==============+===============+
+-------+-------------------------+--------------------+ | 7 | TBD | ACME Node ID | This |
| | | Validation | specification |
+-------------------------+-------+--------------+---------------+
Table 3 Table 3
8. 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 generation.
9. References 10. References
9.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>.
[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/>.
[IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers",
<https://www.iana.org/assignments/smi-numbers/>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, Classes and Attribute Types Version 2.0", RFC 2985,
DOI 10.17487/RFC2985, November 2000, DOI 10.17487/RFC2985, November 2000,
<https://www.rfc-editor.org/info/rfc2985>. <https://www.rfc-editor.org/info/rfc2985>.
skipping to change at page 18, line 17 skipping to change at page 20, line 32
Version 7", Work in Progress, Internet-Draft, draft-ietf- Version 7", Work in Progress, Internet-Draft, draft-ietf-
dtn-bpbis-31, 25 January 2021, 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 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-26, 8 January 2021, ietf-dtn-bpsec-26, 8 January 2021,
<https://tools.ietf.org/html/draft-ietf-dtn-bpsec-26>. <https://tools.ietf.org/html/draft-ietf-dtn-bpsec-26>.
9.2. Informative References 10.2. Informative References
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[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-13, 20 November 2020, <https://tools.ietf.org/html/ smime-13, 20 November 2020, <https://tools.ietf.org/html/
draft-ietf-acme-email-smime-13>. 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
skipping to change at page 18, line 39 skipping to change at page 21, line 12
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-24, 7 December 2020,
<https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-24>. <https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-24>.
[I-D.sipos-dtn-udpcl]
Sipos, B., "Delay-Tolerant Networking UDP Convergence
Layer Protocol", Work in Progress, Internet-Draft, draft-
sipos-dtn-udpcl-01, 26 March 2021,
<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- Contexts", Work in Progress, Internet-Draft, draft-bsipos-
dtn-bpsec-cose-04, 22 December 2020, dtn-bpsec-cose-04, 22 December 2020,
<https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose- <https://tools.ietf.org/html/draft-bsipos-dtn-bpsec-cose-
04>. 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/>.
skipping to change at page 20, line 41 skipping to change at page 23, line 38
] ]
Figure 1: Example Challenge Bundle Figure 1: 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 fingerprint, 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.LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" "p3yRYFU4KxwQaHQjJ2RdiQtPUZNY4ONIk6LxErRFEjVw."
"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
The minimal-but-valid Response Bundle is shown in Figure 2. This The minimal-but-valid Response Bundle is shown in Figure 2. 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 /
skipping to change at page 21, line 21 skipping to change at page 24, line 21
[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 /
], ],
[ [
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 / <<[ / block-type-specific data /
0xFFFF, / record-type-code / 0xFFFF, / record-type-code /
{ / record-content / { / record-content /
1: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-part1 / 1: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-part1 /
2: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew' / key auth. digest / 2: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew'
/ key auth. digest /
} }
]>> ]>>
] ]
] ]
Figure 2: Example Response Bundle Figure 2: Example Response Bundle
Author's Address Author's Address
Brian Sipos Brian Sipos
 End of changes. 65 change blocks. 
181 lines changed or deleted 329 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/