draft-ietf-acme-dtnnodeid-05.txt   draft-ietf-acme-dtnnodeid-06.txt 
Automated Certificate Management Environment B. Sipos Automated Certificate Management Environment B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Updates: -ietf-dtn-bpbis (if approved) 22 September 2021 Intended status: Experimental 13 October 2021
Intended status: Experimental Expires: 16 April 2022
Expires: 26 March 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-05 draft-ietf-acme-dtnnodeid-06
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".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 26 March 2022. This Internet-Draft will expire on 16 April 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 2, line 29 skipping to change at page 2, line 29
1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. Bundle Endpoint ID ACME Identifier . . . . . . . . . . . . . 7 2. Bundle Endpoint ID ACME Identifier . . . . . . . . . . . . . 7
3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 8 3. DTN Node ID Validation . . . . . . . . . . . . . . . . . . . 8
3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 11 3.1. DTN Node ID Challenge Request Object . . . . . . . . . . 11
3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 12 3.2. DTN Node ID Challenge Response Object . . . . . . . . . . 12
3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 13 3.3. ACME Node ID Validation Challenge Bundles . . . . . . . . 13
3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 14 3.3.1. Challenge Bundle Checks . . . . . . . . . . . . . . . 14
3.4. ACME Node ID Validation Response Bundles . . . . . . . . 14 3.4. ACME Node ID Validation Response Bundles . . . . . . . . 14
3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 16 3.4.1. Response Bundle Checks . . . . . . . . . . . . . . . 16
4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 16 3.5. Multi-Perspective Validation . . . . . . . . . . . . . . 16
4. Bundle Integrity Gateway . . . . . . . . . . . . . . . . . . 17
5. Certificate Request Profile . . . . . . . . . . . . . . . . . 17 5. Certificate Request Profile . . . . . . . . . . . . . . . . . 17
5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 17 5.1. Multiple Identity Claims . . . . . . . . . . . . . . . . 18
5.2. Generating Encryption-only or Signing-only Bundle Security 5.2. Generating Encryption-only or Signing-only Bundle Security
Certificates . . . . . . . . . . . . . . . . . . . . . . 17 Certificates . . . . . . . . . . . . . . . . . . . . . . 18
6. Bundle Protocol Administrative Record Types Registry . . . . 18 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.1. Threat: Passive Leak of Validation Data . . . . . . . . . 19
8.1. Threat: Passive Leak of Validation Data . . . . . . . . . 19 7.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 20
8.2. Threat: BP Node Impersonation . . . . . . . . . . . . . . 19 7.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 20
8.3. Threat: Bundle Replay . . . . . . . . . . . . . . . . . . 20 7.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 20
8.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 20 7.5. Inherited Security Considerations . . . . . . . . . . . . 21
8.5. Inherited Security Considerations . . . . . . . . . . . . 21 7.6. Out-of-Scope BP Agent Communication . . . . . . . . . . . 21
8.6. Out-of-Scope BP Agent Communication . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 22
9.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 22 8.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 22
9.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 22 8.3. Bundle Administrative Record Types . . . . . . . . . . . 22
9.3. Bundle Administrative Record Types . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Administrative Record Types CDDL . . . . . . . . . . 27 Appendix A. Administrative Record Types CDDL . . . . . . . . . . 27
Appendix B. Example Authorization . . . . . . . . . . . . . . . 27 Appendix B. Example Authorization . . . . . . . . . . . . . . . 27
B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 28 B.1. Challenge Bundle . . . . . . . . . . . . . . . . . . . . 27
B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 28 B.2. Response Bundle . . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
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 otherName with a name form of Subject Alternative Name (SAN) of type otherName with a name form of
"bundleEID", which used to represent an Endpoint ID (EID) for a BundleEID, which used to represent an Endpoint ID (EID) for a Delay-
Delay-Tolerant Networking (DTN) bundle. Currently the URI schemes Tolerant Networking (DTN) bundle. Currently the URI schemes "dtn"
"dtn" and "ipn" as defined in [I-D.ietf-dtn-bpbis] are valid for an and "ipn" as defined in [I-D.ietf-dtn-bpbis] are valid for an
Endpoint ID. A DTN Node ID is an Endpoint ID with scheme-specific Endpoint ID. A DTN Node ID is an Endpoint ID with scheme-specific
restrictions to identify it as such; currently the "dtn" scheme uses restrictions to identify it as such; currently the "dtn" scheme uses
an empty demux part and the "ipn" scheme uses service number zero. an empty demux part and the "ipn" scheme uses service number zero.
Because the SAN URI claim is new to ACME, a new ACME Identifier type Because the BundleEID claim is new to ACME, a new ACME Identifier
"bundleEID" is needed to manage this claim within ACME messaging. A type "bundleEID" is needed to manage this claim within ACME
"bundleEID" claim can be part of a pre-authorization or as one of the messaging. A "bundleEID" claim can be part of a pre-authorization or
authorizations of an order containing any number of claims. as one of the authorizations of an order containing any number of
claims.
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 "bundleEID" or as one of the authorizations of authorization of the "bundleEID" or as one of the authorizations of
an order containing a "bundleEID", the client can finalize the order an order containing a "bundleEID", the client can finalize the order
using an associated certificate signing request (CSR). Because a using an associated certificate signing request (CSR). Because a
single order can contain multiple identifiers of multiple types, single order can contain multiple identifiers of multiple types,
there can be operational issues for a client attempting to, and there can be operational issues for a client attempting to, and
possibly failing to, validate those multiple identifiers as described possibly failing to, validate those multiple identifiers as described
in Section 5.1. Once a certificate is issued for a Node ID, how the in Section 5.1. Once a certificate is issued for a Node ID, how the
ACME client configures the Bundle Protocol (BP) agent with the new ACME client configures the Bundle Protocol (BP) agent with the new
certificate is an implementation matter. certificate is 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 [RFC8823]. that of secured email validation of [RFC8823].
This document also updates BPv7 to explicitly use the IANA
administrative record type registry in Section 6.
1.1. Scope 1.1. Scope
This document describes the ACME messages, BPv7 payloads, and BPSec This document describes the ACME messages, BPv7 payloads, and BPSec
requirements needed to validate Node ID ownership. This document requirements needed to validate Node ID ownership. This document
does not address: does not address:
* Mechanisms for communication between ACME client or ACME server * Mechanisms for communication between ACME client or ACME server
and their associated BP agent(s). This document only describes and their associated BP agent(s). This document only describes
exchanges between ACME client--server pairs and between their BP exchanges between ACME client--server pairs and between their BP
agents. agents.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
| ACME |<===== HTTPS exchanges =====>| ACME | | ACME |<===== HTTPS exchanges =====>| ACME |
| Client | | Server | | Client | | Server |
+------------+ +------------+ +------------+ +------------+
| | ^ | | ^
(1) Enable or (6) disable (2) Send | | (1) Enable or (6) disable (2) Send | |
validation from server Challenge | |(5) Indicate validation from server Challenge | |(5) Indicate
| Non-DTN | | Response | Non-DTN | | Response
~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~|~~~~~~~~~~~~ ~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~|~~~~~~~~~~~~
V DTN V | V DTN V |
++------------++ ++------------++ ++------------++ ++------------++
|| Admin Elem.|| || Admin Elem.|| || Admin Elem.|| || Admin Elem.||-+
|+------------+| (3) Challenge |+------------+| |+------------+| (3) Challenge |+------------+| |
| Client's |<------------- Bundle -----| Server's | | Client's |<------------- Bundle -----| Server's | |
| BP Agent | | BP Agent | | BP Agent | | BP Agent | |
+--------------+ +--------------+ +--------------+ +--------------+ |
| ^ | +----^---------+
| +-------------+ | | +-------------+ |
| | Integrity | (4) Response | | | Integrity | (4) Response |
+---->| Gateway |------ Bundle --------+ +---->| Gateway |------ Bundle --------+
+-------------+ +-------------+
Figure 1: The relationships and flows between Node ID Validation Figure 1: The relationships and flows between Node ID Validation
entities entities
Because the DTN Node ID is used both for routing bundles between BP Because the DTN Node ID is used both for routing bundles between BP
agents and for multiplexing administrative services within a BP agents and for multiplexing administrative services within a BP
skipping to change at page 7, line 51 skipping to change at page 7, line 51
This specification is the first to make use of an Bundle Endpoint ID This specification is the first to make use of an Bundle Endpoint ID
to identify a claim for a certificate request in ACME. In this to identify a claim for a certificate request in ACME. In this
document, the only purpose for which an Bundle Endpoint ID ACME document, the only purpose for which an Bundle Endpoint ID ACME
identifier is validated is as a DTN Node ID (see Section 3), but identifier is validated is as a DTN Node ID (see Section 3), but
other specifications can define challenge types for other Endpoint ID other specifications can define challenge types for other Endpoint ID
uses. uses.
Identifiers of type "bundleEID" in certificate requests MUST appear Identifiers of type "bundleEID" in certificate requests MUST appear
in an extensionRequest attribute [RFC2985] containing a in an extensionRequest attribute [RFC2985] containing a
subjectAltName extension of type otherName with a name form of subjectAltName extension of type otherName with a name form of
"bundleEID" consistent with the requirements of Section 4.4.2.1 of BundleEID, identified by id-on-bundleEID of [IANA-SMI], consistent
[I-D.ietf-dtn-tcpclv4]. Because the bundleEID is encoded as an with the requirements of Section 4.4.2.1 of [I-D.ietf-dtn-tcpclv4].
IA5String it SHALL be treated as being in the percent-encoded form of
Section 2.1 of [RFC3986]. Any "bundleEID" identifier which fails to Because the BundleEID is encoded as an IA5String it SHALL be treated
properly percent-decode SHALL be rejected with an ACME error type of as being in the percent-encoded form of Section 2.1 of [RFC3986].
"malformed". Any "bundleEID" identifier which fails to properly percent-decode
SHALL be rejected with an ACME error type of "malformed".
The ACME server SHALL decode and normalize (based on scheme-specific The ACME server SHALL decode and normalize (based on scheme-specific
syntax) all received identifiers of type "bundleEID". Any syntax) all received identifiers of type "bundleEID". Any
"bundleEID" identifier request which uses a scheme not handled by the "bundleEID" identifier request which uses a scheme not handled by the
ACME server or for which the URI does not match the scheme-specific ACME server or for which the EID does not match the scheme-specific
syntax SHALL be rejected with an ACME error type of syntax SHALL be rejected with an ACME error type of
"rejectedIdentifier". "rejectedIdentifier".
When an ACME server needs to request proof that a client controls a When an ACME server needs to request proof that a client controls a
URI, it SHALL create an authorization with the identifier type BundleEID, it SHALL create an authorization with the identifier type
"bundleEID". The ACME server SHALL NOT attempt to dereference the "bundleEID". The ACME server SHALL NOT attempt to dereference the
Endpoint ID value on its own. It is the responsibility of a EID value on its own. It is the responsibility of a validation
validation method to ensure the URI ownership via scheme-specific method to ensure the EID ownership via scheme-specific means
means authorized by the ACME client. authorized by the ACME client.
An identifier for the Node ID of "dtn://example/" would be formatted An identifier for the Node ID of "dtn://example/" would be formatted
as: as:
{"type": "bundleEID", "value": "dtn://example/"} {
"type": "bundleEID",
"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
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 by verifying that received
received Response Bundles correspond with the BP Node and client Response Bundles correspond with the BP Node and client account key
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 constant for, 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.
The DTN Node ID Challenge SHALL only be allowed for URIs usable as a For each ACME server, the pair of token-chal and token-bundle values
DTN Node ID, which are currently the schemes "dtn" and "ipn" as is the unique correlator between Challenge and Response bundles.
defined in [I-D.ietf-dtn-bpbis]. When an ACME server supports Node Because multiple Challenge Bundles can be sent to validate the same
ID validation, the ACME server SHALL define a challenge object in Node ID, the token-bundle in the response is needed to correlate with
accordance with Section 3.1. Once this challenge object is defined, the expected Key Authorization digest.
the ACME client may begin the validation.
The DTN Node ID Challenge SHALL only be allowed for an EID usable as
a DTN Node ID, which [I-D.ietf-dtn-bpbis]. When an ACME server
supports Node ID validation, the ACME server SHALL define a challenge
object in accordance with Section 3.1. Once this challenge object is
defined, the ACME client may begin the validation.
To initiate a Node ID validation, the ACME client performs the To initiate a Node ID validation, the ACME client performs the
following steps: following steps:
1. The ACME client POSTs a newOrder or newAuthz request including 1. The ACME client POSTs a newOrder or newAuthz request including
the identifier of type "bundleEID" for the desired Node ID. From the identifier of type "bundleEID" for the desired Node ID. From
either of these entry points an authorization for the "bundleEID" either of these entry points an authorization for the "bundleEID"
type is indicated by the ACME server. See Section 7.4 of type is indicated by the ACME server. See Section 7.4 of
[RFC8555] for more details. [RFC8555] for more details.
2. The ACME client obtains the challenge source Node ID and "token- 2. The ACME client obtains the challenge source Node ID and token-
chal" from the challenge object in accordance with Section 3.1. chal from the challenge object in accordance with Section 3.1.
3. The ACME client indicates to the administrative element of its BP 3. The ACME client indicates to the administrative element of its BP
agent the source Node ID and challenge "token-chal" which is agent the source Node ID and challenge token-chal which is
authorized for use and the associated client account key authorized for use and the associated client account key
thumbprint. The ACME client SHALL wait, if necessary, until the thumbprint. The ACME client SHALL wait, if necessary, until the
agent is configured before proceeding to the next step. agent is configured before proceeding to the next step.
4. The ACME client POSTs a challenge response to the challenge URL 4. The ACME client POSTs a challenge response to the challenge URL
on the ACME server accordance with Section 7.5.1 of [RFC8555]. on the ACME server accordance with Section 7.5.1 of [RFC8555].
The payload object is constructed in accordance with Section 3.2. The payload object is constructed in accordance with Section 3.2.
5. The administrative element waits for a Challenge Bundle to be 5. The administrative element waits for a Challenge Bundle to be
received with the authorized ACME parameters, including its received with the authorized ACME parameters, including its
"token-bundle" payload, in accordance with Section 3.3. token-bundle payload, in accordance with Section 3.3.
6. The administrative element concatenates "token-bundle" with 6. The administrative element concatenates token-bundle with token-
"token-chal" (each as base64url-encoded text strings) and chal (each as base64url-encoded text strings) and computes the
computes the Key Authorization in accordance with Section 8.1 of Key Authorization in accordance with Section 8.1 of [RFC8555]
[RFC8555] using the full token and client account key thumbprint. using the full token and client account key thumbprint.
7. The administrative element computes the SHA-256 digest of the Key 7. The administrative element computes the SHA-256 digest of the Key
Authorization result and generates a Response Bundle to send back Authorization result and generates a Response Bundle to send back
to the ACME server in accordance with Section 3.4. to the ACME server in accordance with Section 3.4.
8. The ACME client waits for the authorization to be finalized on 8. The ACME client waits for the authorization to be finalized on
the ACME server in accordance with Section 7.5.1 of [RFC8555]. the ACME server in accordance with Section 7.5.1 of [RFC8555].
9. Once the challenge is completed (successfully or not), the ACME 9. Once the challenge is completed (successfully or not), the ACME
client indicates to the BP agent that the validation source and client indicates to the BP agent that the validation source and
"token-chal" is no longer usable. If the authorization fails, token-chal is no longer usable. If the authorization fails, the
the ACME client MAY retry the challenge from Step 3. ACME client MAY retry the challenge from Step 3.
The ACME server verifies the client's control over a Node ID by The ACME server verifies the client's control over a Node ID by
performing the following steps: performing the following steps:
1. The ACME server receives a newOrder or newAuthz request including 1. The ACME server receives a newOrder or newAuthz request including
the identifier of type "bundleEID", where the URI value is a Node the identifier of type "bundleEID", where the URI value is a Node
ID. ID.
2. The ACME server generates an authorization for the Node ID with 2. The ACME server generates an authorization for the Node ID with
challenge type "dtn-nodeid-01" in accordance with Section 3.1. challenge type "dtn-nodeid-01" in accordance with Section 3.1.
3. The ACME server receives a POST to the challenge URL indicated 3. The ACME server receives a POST to the challenge URL indicated
from the authorization object. The payload is handled in from the authorization object. The payload is handled in
accordance with Section 3.2. accordance with Section 3.2.
4. The ACME server sends, via the administrative element of its BP 4. The ACME server sends, via the administrative element of its BP
agent, one or more Challenge Bundles in accordance with agent, one or more Challenge Bundles in accordance with
Section 3.3. Each challenge bundle SHALL contain a distinct Section 3.3. Each challenge bundle SHALL contain a distinct
"token-bundle" to be able to correlate with a response bundle. token-bundle to be able to correlate with a response bundle.
Computing an expected Key Authorization digest is not necessary Computing an expected Key Authorization digest is not necessary
until a response is received. until a response is received.
5. The ACME server waits for Response Bundle(s) for a limited 5. The ACME server waits for Response Bundle(s) for a limited
interval of time (based on the challenge response object of interval of time (based on the challenge response object of
Section 3.2). Responses are encoded in accordance with Section 3.2). Responses are encoded in accordance with
Section 3.4. Section 3.4.
6. Once received and decoded, the ACME server checks the contents of 6. Once received and decoded, the ACME server checks the contents of
each Response Bundle in accordance with Section 3.4.1. After all each Response Bundle in accordance with Section 3.4.1. After all
Challenge Bundles have either been responded to or timed-out, the Challenge Bundles have either been responded to or timed-out, the
validation procedure is successful only if all responses are ACME server policy (see Section 3.5) determines whether the
successful. If validation is not successful, a client may retry validation is successful. If validation is not successful, a
the challenge which starts in Step 3. client may retry the challenge which starts in Step 3.
An ACME server MAY send multiple challenges from different origins in
the DTN network to avoid possible on-path attacks, as recommended in
Section 10.2 of [RFC8555]. If responses are received from multiple
challenges, any response failure SHALL cause a failure of the overall
validation. Each response failure MAY be indicated to the ACME
client as a validation subproblem.
When responding to a Challenge Bundle, a BP agent SHALL send a single When responding to a Challenge Bundle, a BP agent SHALL send a single
Response Bundle in accordance with Section 3.4. A BP agent SHALL Response Bundle in accordance with Section 3.4. A BP agent SHALL
respond to ACME challenges only within the interval of time, only for respond to ACME challenges only within the interval of time, only for
the Node ID, and only for the "token-chal" indicated by the ACME the Node ID, and only for the token-chal indicated by the ACME
client. A BP agent SHALL respond to multiple challenges with the client. A BP agent SHALL respond to multiple Challenge Bundles with
same parameters. These correspond with the ACME server validating the same ACME parameters but different bundle identities (source Node
ID and timestamp); these correspond with the ACME server validating
via multiple routing paths. via multiple routing paths.
3.1. DTN Node ID Challenge Request Object 3.1. DTN Node ID Challenge Request Object
The DTN Node ID Challenge request object is defined by the ACME The DTN Node ID Challenge request object is defined by the ACME
server when it supports validating Node IDs. server when it supports validating Node IDs.
The DTN Node ID Challenge request object has the following content: The DTN Node ID Challenge request object has the following content:
type (required, string): The string "dtn-nodeid-01". type (required, string): The string "dtn-nodeid-01".
source (required, string): The source Node ID of bundles originating source (required, array of string): An unordered list of possible
at the ACME server as a text URI. source Node ID of bundles originating at the BP agent(s) of the
ACME server. See Section 3.5 for a discussion of multi-
perspective validation using multiple sources. The array SHALL be
non-empty. The array MAY contain Node IDs which are not actually
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 NOT contain any characters outside the of entropy. It MUST contain any characters outside the base64url
base64url alphabet as described in Section 5 of [RFC4648]. alphabet as described in Section 5 of [RFC4648]. Trailing '='
Trailing '=' padding characters MUST be stripped. See [RFC4086] padding characters MUST be stripped. See [RFC4086] for additional
for additional information on randomness requirements. 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 The token-chal value included in this object is fixed for the entire
entire challenge, and may correspond with multiple separate "token- challenge, and may correspond with multiple separate token-bundle
bundle" values when multiple Challenge Bundles are sent for a single values when multiple Challenge Bundles are sent for a single
validation. validation.
3.2. DTN Node ID Challenge Response Object 3.2. DTN Node ID Challenge Response Object
The DTN Node ID Challenge response object is defined by the ACME The DTN Node ID Challenge response object is defined by the ACME
client when it authorizes validation of a Node ID. Because a DTN has client when it authorizes validation of a Node ID. Because a DTN has
the potential for significantly longer delays than a non-DTN network, the potential for significantly longer delays than a non-DTN network,
the ACME client is able to inform the ACME server if a particular the ACME client is able to inform the ACME server if a particular
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 13, line 20 skipping to change at page 13, line 20
Each Challenge Bundle has parameters as listed here: Each Challenge Bundle has parameters as listed here:
Bundle Processing Control Flags: The primary block flags SHALL Bundle Processing Control Flags: The primary block flags SHALL
indicate that the payload is an administrative record. The indicate that the payload is an administrative record. The
primary block flags SHALL indicate that user application primary block flags SHALL indicate that user application
acknowledgement is requested; this flag distinguishes the acknowledgement is requested; this flag distinguishes the
Challenge Bundle from the Response Bundle. The primary block Challenge Bundle from the Response Bundle. 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 the ACME-server-
ID being validated. The ACME server SHOULD NOT perform URI normalized Node ID being validated.
normalization on the Node ID given by the ACME client.
Source Node ID: The Source Node ID SHALL indicate the Node ID of the Source Node ID: The Source Node ID SHALL indicate the Node ID of the
BP agent of the ACME server performing the challenge. BP agent of the ACME server performing the challenge. The
challenge bundle source SHALL be present in the "source" array of
the challenge object (see Section 3.1)
Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set
to the time at which the challenge was generated. The Lifetime to the time at which the challenge was generated. The Lifetime
SHALL indicate the response interval (of Section 3.2) for which SHALL indicate the response interval (of Section 3.2) for which
ACME server will accept responses to this challenge. ACME server will accept responses to this challenge.
Administrative Record Type Code: Set to the ACME Node ID Validation Administrative Record Type Code: Set to the ACME Node ID Validation
type code defined in Section 9.3. type code defined in Section 8.3.
Administrative Record Content: The Challenge Bundle administrative Administrative Record Content: The Challenge Bundle administrative
record content SHALL consist of a CBOR map containing two pairs: record content SHALL consist of a CBOR map containing two pairs:
* One pair SHALL consist of key 1 with value of ACME challenge * One pair SHALL consist of key 1 with value of ACME challenge
"token-chal", copied from the challenge object, represented as token-chal, copied from the challenge object, represented as a
a CBOR byte string. CBOR byte string.
* One pair SHALL consist of key 2 with value of ACME challenge * One pair SHALL consist of key 2 with value of ACME challenge
"token-bundle", represented as a CBOR byte string. The "token- token-bundle, represented as a CBOR byte string. The token-
bundle" is a random value that uniquely identifies the bundle is a random value that uniquely identifies the challenge
challenge bundle. This value MUST have at least 128 bits of bundle. This value MUST have at least 128 bits of entropy.
entropy. See [RFC4086] for additional information on See [RFC4086] for additional information on randomness
randomness requirements. requirements.
This structure is part of the extension CDDL in Appendix A. An This structure is part of the extension CDDL in Appendix A. An
example full Challenge Bundle is included in Appendix B.1 example full Challenge Bundle is included in Appendix B.1
If the BP agent generating a Challenge Bundle does not have a well- If the BP agent generating a Challenge Bundle does not have a well-
synchronized clock or the agent responding to the challenge is synchronized clock or the agent responding to the challenge is
expected to not have a well-synchronized clock, the bundle SHALL expected to not have a well-synchronized clock, the bundle SHALL
include a Bundle Age extension block. include a Bundle Age extension block.
Challenge Bundles SHALL include a Block Integrity Block (BIB) in Challenge Bundles SHALL include a Block Integrity Block (BIB) in
accordance with Section 4 or with a Security Source identical to the accordance with Section 4 or with a Security Source identical to the
bundle Source Node. Challenge Bundles SHALL NOT be directly bundle Source Node. Challenge Bundles SHALL NOT be directly
encrypted by Block Confidentiality Block (BCB) or any other method encrypted by Block Confidentiality Block (BCB) or any other method
(see Section 8.1). (see Section 7.1).
3.3.1. Challenge Bundle Checks 3.3.1. Challenge Bundle Checks
A proper Challenge Bundle meets all of the following criteria: A proper Challenge Bundle meets all of the following criteria:
* The Challenge Bundle was received within the time interval allowed * The Challenge Bundle was received within the time interval allowed
for the challenge. The allowed interval starts at the Creation for the challenge. The allowed interval starts at the Creation
Timestamp and extends for the Lifetime of the Challenge Bundle. Timestamp and extends for the Lifetime of the Challenge Bundle.
* The Challenge Bundle Source Node ID is identical to the Node ID * The Challenge Bundle Source Node ID is identical to the Node ID
indicated in the ACME challenge object. The comparison of Node indicated in the ACME challenge object. The comparison of Node
IDs SHALL use the comparison logic of [RFC3986] and scheme-based IDs SHALL use the comparison logic of the NODE-ID from
normalization of those schemes specified in [I-D.ietf-dtn-bpbis]. Section 4.4.1 of [I-D.ietf-dtn-tcpclv4].
* The Challenge Bundle contains a BIB which covers at least the * The Challenge Bundle contains a BIB which covers at least the
primary block and payload. That BIB has a security source which primary block and payload. That BIB has a security source which
is trusted and passes security-context-specific validation (i.e. is trusted and passes security-context-specific validation (i.e.
MAC or signature verification). MAC or signature verification).
* The challenge payload contains the "token-chal" as indicated in * The challenge payload contains the token-chal as indicated in the
the ACME challenge object. The challenge payload contains a ACME challenge object. The challenge payload contains a token-
"token-bundle" meeting the definition in Section 3.3. bundle meeting the definition in Section 3.3.
Any of the failures above SHALL cause the challenge bundle to be Any of the failures above SHALL cause the challenge bundle to be
deleted and otherwise ignored by the BP agent. The BP agent MAY send deleted and otherwise ignored by the BP agent. The BP agent MAY send
status reports about the deletion if allowed by security policy. status reports about the deletion if allowed by security policy.
3.4. ACME Node ID Validation Response Bundles 3.4. ACME Node ID Validation Response Bundles
Each ACME Node ID Validation Response Bundle SHALL be structured and Each ACME Node ID Validation Response Bundle SHALL be structured and
encoded in accordance with [I-D.ietf-dtn-bpbis]. encoded in accordance with [I-D.ietf-dtn-bpbis].
skipping to change at page 15, line 22 skipping to change at page 15, line 22
Source Node ID: The Source Node ID SHALL be identical to the Source Node ID: The Source Node ID SHALL be identical to the
Destination EID of the Challenge Bundle to which this response Destination EID of the Challenge Bundle to which this response
corresponds. corresponds.
Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set Creation Timestamp and Lifetime: The Creation Timestamp SHALL be set
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 9.3. type code defined in Section 8.3.
Administrative Record Content: The Response Bundle administrative Administrative Record Content: The Response Bundle administrative
record content SHALL consist of a CBOR map containing three pairs: record content SHALL consist of a CBOR map containing three pairs:
* One pair SHALL consist of key 1 with value of ACME challenge * One pair SHALL consist of key 1 with value of ACME challenge
"token-chal", copied from the Request Bundle, represented as a token-chal, copied from the Request Bundle, represented as a
CBOR byte string. CBOR byte string.
* One pair SHALL consist of key 2 with value of ACME challenge * One pair SHALL consist of key 2 with value of ACME challenge
"token-bundle", copied from the Request Bundle, represented as token-bundle, copied from the Request Bundle, represented as a
a CBOR byte string. CBOR byte string.
* One pair SHALL consist of key 3 with value of the SHA-256 * One pair SHALL consist of key 3 with value of the SHA-256
digest [FIPS180-4] of the ACME Key Authorization in accordance digest [FIPS180-4] of the ACME Key Authorization in accordance
with Section 8.1 of [RFC8555], represented as a CBOR byte with Section 8.1 of [RFC8555], represented as a CBOR byte
string. string.
This structure is part of the extension CDDL in Appendix A. An This structure is part of the extension CDDL in Appendix A. An
example full Response Bundle is included in Appendix B.2 example full Response Bundle is included in Appendix B.2
If the BP agent responding to a Challenge Bundle does not have a If the BP agent responding to a Challenge Bundle does not have a
well-synchronized clock, it SHALL use any information about last-hop well-synchronized clock, it SHALL use any information about last-hop
delays and (if present) Bundle Age extension data to infer the age of delays and (if present) Bundle Age extension data to infer the age of
the Challenge Bundle and lifetime of the Response Bundle. the Challenge Bundle and lifetime of the Response Bundle.
Response Bundles SHALL include a BIB in accordance with Section 4. Response Bundles SHALL include a BIB in accordance with Section 4.
Response Bundles SHALL NOT be directly encrypted by BCB or any other Response Bundles SHALL NOT be directly encrypted by BCB or any other
method (see Section 8.1 for explanation). method (see Section 7.1 for explanation).
3.4.1. Response Bundle Checks 3.4.1. Response Bundle Checks
A proper Response Bundle meets all of the following criteria: A proper Response Bundle meets all of the following criteria:
* The Response Bundle was received within the time interval allowed * The Response Bundle was received within the time interval allowed
for the challenge. The allowed interval starts at the Creation for the challenge. The allowed interval starts at the Creation
Timestamp and extends for the Lifetime of the Response Bundle. Timestamp and extends for the Lifetime of the associated Challenge
Bundle. The interval of the Challenge Bundle is used here because
the interval of the Response Bundle could be made to disagree with
the Challenge Bundle.
* 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 the NODE-ID from Section 4.4.1 of
those schemes specified in [I-D.ietf-dtn-bpbis]. [I-D.ietf-dtn-tcpclv4].
* The Response Bundle contains a BIB which covers at least the * The Response Bundle contains a BIB which covers at least the
primary block and payload. That BIB has a security source which primary block and payload. That BIB has a security source which
is trusted and passes security-context-specific validation. is trusted and passes security-context-specific validation.
* The response payload contains the "token-chal" and "token-bundle" * The response payload contains the same token-chal and token-bundle
as sent in the Challenge Bundle. The response payload contains as sent in the Challenge Bundle (this is also how the two bundles
the expected Key Authorization digest computed by the ACME server. are correlated). The response payload contains the expected Key
Because multiple Challenge Bundles can be sent to validate the Authorization digest computed by the ACME server.
same Node ID, the "token-bundle" in the response is needed to
correlate with the expected Key Authorization digest.
Any of the failures above SHALL cause the validation to fail with an Any of the failures above SHALL cause that single-perspective
ACME error type of "incorrectResponse". Any of the failures above validation to fail. Any of the failures above SHOULD be
SHOULD be indicated as subproblems to the ACME client. The lack of a distinguished as subproblems to the ACME client. The lack of a
response within the expected response interval, as defined in response within the expected response interval, as defined in
Section 3.2, SHALL also be treated as a validation failure. Section 3.2, SHALL also be treated as a validation failure.
3.5. Multi-Perspective Validation
To avoid possible on-path attacks in certain networks, an ACME server
can perform a single validation using multiple challenge bundle
sources or via multiple routing paths. This technique is called
multi-perspective validation as recommended in Section 10.2 of
[RFC8555] and an implementation used by Let's Encrypt is described in
[LE-multi-perspective].
When required by policy, an ACME server SHALL send multiple challenge
bundles from different sources in the DTN network. When multiple
Challenge Bundles are sent for a single validation, it is a matter of
ACME server policy to determine whether or not the validation as a
whole is successful. The result of each single-source validation is
defined as success or failure in Section 3.4.1.
A RECOMMENDED validation policy is to succeed if the challenge from a
primary bundle source is successful and if there are no more than one
failure from a secondary source. The determination of which
perspectives are considered primary or secondary is an implementation
matter.
Regardless of whether a validation is single- or multi-perspective, a
validation failure SHALL be indicated by an ACME error type of
"incorrectResponse". Each specific perspective failure SHOULD be
indicated to the ACME client as a validation subproblem.
4. Bundle Integrity Gateway 4. Bundle Integrity Gateway
This section defines a BIB use which closely resembles the function This section defines a BIB use which closely resembles the function
of DKIM email signing [RFC6376]. In this mechanism a routing node in of DKIM email signing [RFC6376]. In this mechanism a routing node in
a DTN sub-network attests to the origination of a bundle by adding a a DTN sub-network attests to the origination of a bundle by adding a
BIB before forwarding it. The bundle receiver then need not trust BIB before forwarding it. The bundle receiver then need not trust
the source of the bundle, but only trust this security source node. the source of the bundle, but only trust this security source node.
The receiver needs policy configuration to know which security The receiver needs policy configuration to know which security
sources are permitted to attest for which bundle sources. sources are permitted to attest for which bundle sources.
skipping to change at page 17, line 11 skipping to change at page 17, line 41
source could also add its own BIB with a local-network-specific source could also add its own BIB with a local-network-specific
security context or local-network-specific key material (i.e. a group security context or local-network-specific key material (i.e. a group
key shared within the local network). key shared within the local network).
When an integrity gateway adds a BIB it SHALL be in accordance with 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 [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 block and the primary block (either directly as a target or as
additional authenticated data for the payload block MAC/signature). additional authenticated data for the payload block MAC/signature).
The Security Source of this BIB SHALL be either the bundle source 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 Node ID itself or a routing node trusted by the destination node (see
Section 8.2). Section 7.2).
5. Certificate Request Profile 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], [I-D.sipos-dtn-udpcl], and [I-D.ietf-dtn-tcpclv4], [I-D.sipos-dtn-udpcl], and
[I-D.bsipos-dtn-bpsec-cose]. These purposes are referred to here as [I-D.bsipos-dtn-bpsec-cose]. These purposes are referred to here as
bundle security certificates. bundle security certificates.
One defining aspect of bundle security certificates is the Extended One defining aspect of bundle security certificates is the Extended
Key Usage key purpose "id-kp-bundleSecurity" of [IANA-SMI]. When Key Usage key purpose id-kp-bundleSecurity of [IANA-SMI]. When
requesting a certificate which includes a Node ID SAN, the CSR SHOULD requesting a certificate which includes a Node ID SAN, the CSR SHOULD
include an Extended Key Usage of id-kp-bundleSecurity. When a bundle include an Extended Key Usage of id-kp-bundleSecurity. When a bundle
security certificate is issued based on a validated Node ID SAN, the security certificate is issued based on a validated Node ID SAN, the
certificate SHALL include an Extended Key Usage of id-kp- certificate SHALL include an Extended Key Usage of id-kp-
bundleSecurity. bundleSecurity.
5.1. Multiple Identity Claims 5.1. Multiple Identity Claims
A single bundle security CSR MAY contain a mixed set of SAN claims, A single bundle security CSR MAY contain a mixed set of SAN claims,
including combinations of "ip", "dns", and "bundleEID" claims. There including combinations of "ip", "dns", and "bundleEID" claims. There
skipping to change at page 18, line 14 skipping to change at page 18, line 47
In order to request encryption only bundle security certificate, the In order to request encryption only bundle security certificate, the
CSR MUST include the key usage extension with keyEncipherment or CSR MUST include the key usage extension with keyEncipherment or
keyAgreement bits set and no other bits set. keyAgreement bits set and no other bits set.
Presence of both of the above sets of key usage bits in the CSR, as Presence of both of the above sets of key usage bits in the CSR, as
well as absence of key usage extension in the CSR, signals to ACME well as absence of key usage extension in the CSR, signals to ACME
server to issue a bundle security certificate suitable for both server to issue a bundle security certificate suitable for both
signing and encryption. signing and encryption.
6. Bundle Protocol Administrative Record Types Registry 6. Implementation Status
This document updates the requirements in Section 6.1 of
[I-D.ietf-dtn-bpbis] to use an existing IANA registry and updates
that sub-registry in Section 9.3.
Instead of using the explicit list of types in Table 3 of
[I-D.ietf-dtn-bpbis], a BP Agent SHALL interpret administrative
record type code values in accordance with the IANA "Administrative
Record Types" sub-registry for entries having a "Bundle Protocol
Version" of 7. Additionally, this document clarifies the zero-value
reservation for BPv7 and makes a reservation of high-valued record
type codes for "private or experimental use" which applies only to
BPv7.
7. Implementation Status
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
[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-dtn-demo-agent] and [github-dtn-wireshark].] [github-dtn-demo-agent] and [github-dtn-wireshark].]
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].
skipping to change at page 19, line 15 skipping to change at page 19, line 32
An example implementation of the this draft of ACME Node ID An example implementation of the this draft of ACME Node ID
Validation has been created as a GitHub project Validation has been created as a GitHub project
[github-dtn-demo-agent] and is intended to use as a proof-of-concept [github-dtn-demo-agent] and is intended to use as a proof-of-concept
and as a possible source of interoperability testing. and as a possible source of interoperability testing.
A Wireshark dissector for of the this draft of ACME Node ID A Wireshark dissector for of the this draft of ACME Node ID
Validation has been created as a GitHub project Validation has been created as a GitHub project
[github-dtn-wireshark] and is intended to be used to inspect and [github-dtn-wireshark] and is intended to be used to inspect and
troubleshoot implementations. troubleshoot implementations.
8. 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].
8.1. Threat: Passive Leak of Validation Data 7.1. Threat: Passive Leak of Validation Data
Because this challenge mechanism is used to bootstrap security Because this challenge mechanism is used to bootstrap security
between DTN Nodes, the challenge and its response are likely to be between DTN Nodes, the challenge and its response are likely to be
transferred in plaintext. The only ACME data present on-the-wire is transferred in plaintext. The only ACME data present on-the-wire is
a random token and a cryptographic digest, so there is no sensitive a random token and a cryptographic digest, so there is no sensitive
data to be leaked within the Node ID Validation bundle exchange. data to be leaked within the Node ID Validation bundle exchange.
Because each challenge uses a separate token, there is no value in an Because each challenge uses a separate token, there is no value in an
on-path attacker seeing the tokens from past challenges and/or on-path attacker seeing the tokens from past challenges and/or
responses. responses.
It is possible for intermediate BP nodes to encapsulate-and-encrypt It is possible for intermediate BP nodes to encapsulate-and-encrypt
Challenge and/or Response Bundles while they traverse untrusted Challenge and/or Response Bundles while they traverse untrusted
networks, but that is a DTN configuration matter outside of the scope networks, but that is a DTN configuration matter outside of the scope
of this document. of this document.
8.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.
The primary mitigation is to delegate bundle integrity sourcing to a The primary mitigation is to delegate bundle integrity sourcing to a
trusted routing node near, in the sense of bundle routing topology, trusted routing node near, in the sense of bundle routing topology,
to the bundle source node as defined in Section 4. This is to the bundle source node as defined in Section 4. This is
functionally similar to DKIM signing of [RFC6376] and provides some functionally similar to DKIM signing of [RFC6376] and provides some
level of bundle origination. level of bundle origination.
Another way to mitigate single-path on-path attacks is to attempt 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 from multiple sources or via multiple
recommended in Section 3. It is not a trivial task to guarantee bundle routing paths, as defined in Section 3.5. It is not a trivial
bundle routing though, so more advanced techniques such as onion task to guarantee bundle routing though, so more advanced techniques
routing (using bundle-in-bundle encapsulation [I-D.ietf-dtn-bibect]) such as onion routing (using bundle-in-bundle encapsulation
could be employed. [I-D.ietf-dtn-bibect]) could be employed.
8.3. Threat: Bundle Replay 7.3. Threat: Bundle Replay
It is possible for an on-path attacker to replay both Challenge It is possible for an on-path attacker to replay both Challenge
Bundles or Response Bundles. Even in a properly-configured DTN it is Bundles or Response Bundles. Even in a properly-configured DTN it is
possible that intermediate bundle routers to use multicast forwarding possible that intermediate bundle routers to use multicast forwarding
of a unicast-destination bundle. of a unicast-destination bundle.
Ultimately, the point of the ACME bundle exchange is to derive a Key Ultimately, the point of the ACME bundle exchange is to derive a Key
Authorization and its cryptographic digest and communicate it back to Authorization and its cryptographic digest and communicate it back to
the ACME server for validation, so the uniqueness of the Key the ACME server for validation, so the uniqueness of the Key
Authorization directly determines the scope of replay validity. The Authorization directly determines the scope of replay validity. The
uniqueness of each "token-bundle" to each challenge bundle ensures uniqueness of each token-bundle to each challenge bundle ensures that
that the Key Authorization is unique to the challenge bundle. The the Key Authorization is unique to the challenge bundle. The
uniqueness of each "token-chal" to the ACME challenge ensures that uniqueness of each token-chal to the ACME challenge ensures that the
the Key Authorization is unique to that ACME challenge. Key Authorization is unique to that ACME challenge.
Having each bundle's primary block and payload block covered by a BIB Having each bundle's primary block and payload block covered by a BIB
from a trusted security source (see Section 4) ensures that a from a trusted security source (see Section 4) ensures that a
replayed bundle cannot be altered in the blocks used by ACME. All replayed bundle cannot be altered in the blocks used by ACME. All
together, these properties mean that there is no degraded security together, these properties mean that there is no degraded security
caused by replay of either a Challenge Bundle or a Response Bundle caused by replay of either a Challenge Bundle or a Response Bundle
even in the case where the primary or payload block is not covered by even in the case where the primary or payload block is not covered by
a BIB. The worst that can come of bundle replay is the waste of a BIB. The worst that can come of bundle replay is the waste of
network resources as described in Section 8.4. network resources as described in Section 7.4.
8.4. Threat: Denial of Service 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 Challenge Bundles to a BP A malicious entity can continually send Challenge Bundles to a BP
agent. The victim BP agent can ignore Challenge Bundles which do not agent. The victim BP agent can ignore Challenge Bundles which do not
conform to the specific time interval and challenge token for which conform to the specific time interval and challenge token for 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.
skipping to change at page 21, line 10 skipping to change at page 21, line 22
A malicious entity can continually send Response Bundles to a BP A malicious entity can continually send Response Bundles to a BP
agent. The victim BP agent can ignore Response Bundles which do not agent. The victim BP agent can ignore Response Bundles which do not
conform to the specific time interval or Source Node ID or challenge conform to the specific time interval or Source Node ID or challenge
token for an active Node ID validation. 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.
8.5. Inherited Security Considerations 7.5. Inherited Security Considerations
Because this protocol relies on ACME for part of its operation, the Because this protocol relies on ACME for part of its operation, the
security considerations of [RFC8555] apply to all ACME client--server security considerations of [RFC8555] apply to all ACME client--server
exchanges during Node ID validation. exchanges during Node ID validation.
Because this protocol relies on BPv7 for part of its operation, the Because this protocol relies on BPv7 for part of its operation, the
security considerations of [I-D.ietf-dtn-bpbis] and security considerations of [I-D.ietf-dtn-bpbis] and
[I-D.ietf-dtn-bpsec] apply to all BP messaging during Node ID [I-D.ietf-dtn-bpsec] apply to all BP messaging during Node ID
validation. validation.
8.6. Out-of-Scope BP Agent Communication 7.6. Out-of-Scope BP Agent Communication
Although messaging between an ACME client or ACME server an its Although messaging between an ACME client or ACME server an its
associated BP agent are out-of-scope for this document, both of those associated BP agent are out-of-scope for this document, both of those
channels are critical to Node ID validation security. Either channel channels are critical to Node ID validation security. Either channel
can potentially leak data or provide attack vectors if not properly can potentially leak data or provide attack vectors if not properly
secured. These channels need to protect against spoofing of secured. These channels need to protect against spoofing of
messaging in both directions to avoid interruption of normal messaging in both directions to avoid interruption of normal
validation sequencing and to prevent false validations from validation sequencing and to prevent false validations from
succeeding. succeeding.
The ACME server and its BP agent exchange the outgoing "token-chal", The ACME server and its BP agent exchange the outgoing token-chal,
"token-bundle", and Key Authorization digest but these values do not token-bundle, and Key Authorization digest but these values do not
need to be confidential (they are also in plaintext over the BP need to be confidential (they are also in plaintext over the BP
channel). channel).
Depending on implementation details, the ACME client might transmit Depending on implementation details, the ACME client might transmit
the client account key thumbprint to its BP agent to allow computing the client account key thumbprint to its BP agent to allow computing
the Key Authorization digest on the BP agent. If an ACME client does the Key Authorization digest on the BP agent. If an ACME client does
transmit its client account key thumbprint to a BP agent, it is transmit its client account key thumbprint to a BP agent, it is
important that this data is kept confidential because it provides the important that this data is kept confidential because it provides the
binding of the client account key to the Node ID validation (as well binding of the client account key to the Node ID validation (as well
as for all other types of ACME validation). Avoiding this as for all other types of ACME validation). Avoiding this
transmission would require a full round-trip between BP agent and transmission would require a full round-trip between BP agent and
ACME client, which can be undesirable if the two are separated by a ACME client, which can be undesirable if the two are separated by a
long-delay network. long-delay network.
9. 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.
9.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] | | uri | This specification and [RFC3986] |
+-------+----------------------------------+ +-------+----------------------------------+
Table 1 Table 1
9.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 | uri | Y | This specification |
+---------------+-----------------+------+--------------------+ +---------------+-----------------+------+--------------------+
Table 2 Table 2
9.3. Bundle Administrative Record Types 8.3. Bundle Administrative Record Types
Within the "Bundle Protocol" registry [IANA-BP], the "Bundle
Administrative Record Types" sub-registry has been updated to include
a leftmost "Bundle Protocol Version" column. The existing sub-
registry entries have been updated to have BP versions as in the
following table.
+=================+=======+===============+======================+
| Bundle Protocol | Value | Description | Reference |
| Version | | | |
+=================+=======+===============+======================+
| 6,7 | 0 | Reserved | [RFC7116] |
+-----------------+-------+---------------+----------------------+
| 6,7 | 1 | Bundle status | [RFC5050] |
| | | report | [I-D.ietf-dtn-bpbis] |
+-----------------+-------+---------------+----------------------+
| 6 | 2 | Custody | [RFC5050] |
| | | signal | |
+-----------------+-------+---------------+----------------------+
| 6,7 | 3-15 | Unassigned | |
+-----------------+-------+---------------+----------------------+
Table 3
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. [NOTE to the RFC Editor: For RFC5050 compatibility the sub-registry.
TBD value needs to be no larger than 15, but such compatibility is
not needed. For BPbis the TBD value needs to be no larger than
65535.]
+=================+==========+======================+===============+ [NOTE to the RFC Editor: For [RFC5050] compatibility the AR-TBD value
| Bundle Protocol | Value | Description | Reference | needs to be no larger than 15, but such compatibility is not needed.
| Version | | | | For BPbis the AR-TBD value needs to be no larger than 65535 as
+=================+==========+======================+===============+ defined by [I-D.sipos-bpv7-admin-iana].]
| 7 | TBD | ACME Node ID | This |
| | | Validation | specification |
+-----------------+----------+----------------------+---------------+
| 7 | 16-65535 | Unassigned | |
+-----------------+----------+----------------------+---------------+
| 7 | >= 65536 | Reserved for | This |
| | | Private or | specification |
| | | Experimental Use | |
+-----------------+----------+----------------------+---------------+
Table 4 +=========================+========+==============+===============+
| Bundle Protocol Version | Value | Description | Reference |
+=========================+========+==============+===============+
| 7 | AR-TBD | ACME Node ID | This |
| | | Validation | specification |
+-------------------------+--------+--------------+---------------+
10. Acknowledgments Table 3
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 issuance. certificate issuance.
The workflow and terminology of this validation method was originally The workflow and terminology of this validation method was originally
copied from the work of Alexey Melnikov in [RFC8823]. copied from the work of Alexey Melnikov in [RFC8823].
11. References 10. References
11.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/>.
skipping to change at page 25, line 50 skipping to change at page 25, line 25
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn- <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpbis-31>. bpbis-31>.
[I-D.ietf-dtn-bpsec] [I-D.ietf-dtn-bpsec]
III, E. J. B. and K. McKeever, "Bundle Protocol Security III, E. J. B. and K. McKeever, "Bundle Protocol Security
Specification", Work in Progress, Internet-Draft, draft- Specification", Work in Progress, Internet-Draft, draft-
ietf-dtn-bpsec-27, 16 February 2021, ietf-dtn-bpsec-27, 16 February 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn- <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpsec-27>. bpsec-27>.
11.2. Informative References 10.2. Informative References
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/info/rfc5050>. 2007, <https://www.rfc-editor.org/info/rfc5050>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission
Protocol (LTP), Compressed Bundle Header Encoding (CBHE),
and Bundle Protocol IANA Registries", RFC 7116,
DOI 10.17487/RFC7116, February 2014,
<https://www.rfc-editor.org/info/rfc7116>.
[RFC8823] Melnikov, A., "Extensions to Automatic Certificate [RFC8823] Melnikov, A., "Extensions to Automatic Certificate
Management Environment for End-User S/MIME Certificates", Management Environment for End-User S/MIME Certificates",
RFC 8823, DOI 10.17487/RFC8823, April 2021, RFC 8823, DOI 10.17487/RFC8823, April 2021,
<https://www.rfc-editor.org/info/rfc8823>. <https://www.rfc-editor.org/info/rfc8823>.
[I-D.ietf-dtn-bibect] [I-D.ietf-dtn-bibect]
Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in
Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18
February 2020, <https://datatracker.ietf.org/doc/html/ February 2020, <https://datatracker.ietf.org/doc/html/
draft-ietf-dtn-bibect-03>. draft-ietf-dtn-bibect-03>.
[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-26, 15 February 2021, tcpclv4-28, 6 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn- <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
tcpclv4-26>. tcpclv4-28>.
[I-D.sipos-dtn-udpcl] [I-D.sipos-dtn-udpcl]
Sipos, B., "Delay-Tolerant Networking UDP Convergence Sipos, B., "Delay-Tolerant Networking UDP Convergence
Layer Protocol", Work in Progress, Internet-Draft, draft- Layer Protocol", Work in Progress, Internet-Draft, draft-
sipos-dtn-udpcl-01, 26 March 2021, sipos-dtn-udpcl-01, 26 March 2021,
<https://datatracker.ietf.org/doc/html/draft-sipos-dtn- <https://datatracker.ietf.org/doc/html/draft-sipos-dtn-
udpcl-01>. udpcl-01>.
[I-D.sipos-bpv7-admin-iana]
Sipos, B., "Bundle Protocol Version 7 Administrative
Record Types Registry", Work in Progress, Internet-Draft,
draft-sipos-bpv7-admin-iana-00, 13 October 2021,
<https://datatracker.ietf.org/doc/html/draft-sipos-bpv7-
admin-iana-00>.
[I-D.bsipos-dtn-bpsec-cose] [I-D.bsipos-dtn-bpsec-cose]
Sipos, B., "DTN Bundle Protocol Security COSE Security Sipos, B., "DTN Bundle Protocol Security COSE Security
Context", Work in Progress, Internet-Draft, draft-bsipos- Context", Work in Progress, Internet-Draft, draft-bsipos-
dtn-bpsec-cose-06, 3 June 2021, dtn-bpsec-cose-06, 3 June 2021,
<https://datatracker.ietf.org/doc/html/draft-bsipos-dtn- <https://datatracker.ietf.org/doc/html/draft-bsipos-dtn-
bpsec-cose-06>. bpsec-cose-06>.
[github-dtn-demo-agent] [github-dtn-demo-agent]
Sipos, B., "Python implementation of basic BPv7-related Sipos, B., "Python implementation of basic BPv7-related
protocols", protocols",
<https://github.com/BSipos-RKF/dtn-demo-agent/>. <https://github.com/BSipos-RKF/dtn-demo-agent/>.
[github-dtn-wireshark] [github-dtn-wireshark]
Sipos, B., "Wireshark Dissectors for BPv7-related Sipos, B., "Wireshark Dissectors for BPv7-related
Protocols", Protocols",
<https://github.com/BSipos-RKF/dtn-wireshark/>. <https://github.com/BSipos-RKF/dtn-wireshark/>.
[LE-multi-perspective]
Aas, J., McCarney, D., and R. Shoemaker, "Multi-
Perspective Validation Improves Domain Validation
Security", 19 February 2020,
<https://letsencrypt.org/2020/02/19/multi-perspective-
validation.html>.
Appendix A. Administrative Record Types CDDL Appendix A. Administrative Record Types CDDL
[NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the [NOTE to the RFC Editor: The "0xFFFF" in this CDDL is replaced by the
"ACME Node ID Validation" administrative record type code.] "ACME Node ID Validation" administrative record type code.]
The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles The CDDL extension of BP [I-D.ietf-dtn-bpbis] for the ACME bundles
is: is:
; All ACME records have the same structure ; All ACME records have the same structure
$admin-record /= [0xFFFF, acme-record] $admin-record /= [0xFFFF, acme-record]
skipping to change at page 27, line 51 skipping to change at page 27, line 41
ID "dtn://acme-client/". The example bundles use no block CRC or ID "dtn://acme-client/". The example bundles use no block CRC or
BPSec integrity, which is for simplicity and is not recommended for BPSec integrity, which is for simplicity and is not recommended for
normal use. The provided figures are extended diagnostic notation normal use. The provided figures are extended diagnostic notation
[RFC8610]. [RFC8610].
For this example the ACME client key thumbprint has the base64url For this example the ACME client key thumbprint has the base64url
encoded value of: encoded value of:
"LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ" "LPJNul-wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ"
And the ACME-server generated "token-chal" has the base64url-encoded And the ACME-server generated token-chal has the base64url-encoded
value of: value of:
"tPUZNY4ONIk6LxErRFEjVw" "tPUZNY4ONIk6LxErRFEjVw"
B.1. Challenge Bundle B.1. Challenge Bundle
For the single challenge bundle in this example, the "token-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 /
skipping to change at page 29, line 51 skipping to change at page 29, line 44
Author's Address Author's Address
Brian Sipos Brian Sipos
RKF Engineering Solutions, LLC RKF Engineering Solutions, LLC
7500 Old Georgetown Road 7500 Old Georgetown Road
Suite 1275 Suite 1275
Bethesda, MD 20814-6198 Bethesda, MD 20814-6198
United States of America United States of America
Email: BSipos@rkf-eng.com Email: brian.sipos+ietf@gmail.com
 End of changes. 85 change blocks. 
233 lines changed or deleted 230 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/