Skip to content

Commit

Permalink
Adding clarification of bundle ID terms.
Browse files Browse the repository at this point in the history
  • Loading branch information
@BrianSipos
BrianSipos committed Jan 11, 2022
1 parent e42e759 commit 22d5be7
Show file tree
Hide file tree
Showing 2 changed files with 62 additions and 22 deletions.
1 change: 1 addition & 0 deletions spec/dictionary.txt
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
ack
acknowledgement
Alexey
anycast
auth
BCB
BCP
Expand Down
83 changes: 61 additions & 22 deletions spec/draft-ietf-acme-dtnnodeid.xml
View file
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ietf-acme-dtnnodeid-07" ipr="trust200902" submissionType="IETF" tocInclude="true" version="3">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ietf-acme-dtnnodeid-08" ipr="trust200902" submissionType="IETF" tocInclude="true" version="3">
<front>
<title abbrev="ACME DTN Node ID">
Automated Certificate Management Environment (ACME)
Delay-Tolerant Networking (DTN) Node ID Validation Extension
</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-acme-dtnnodeid-07"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-acme-dtnnodeid-08"/>
<author fullname="Brian Sipos" initials="B." surname="Sipos">
<organization abbrev="RKF Engineering">RKF Engineering Solutions, LLC</organization>
<address>
Expand Down Expand Up @@ -168,6 +168,10 @@ start = acme-record / bundle / tstr
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
</t>
<t>
Because this document combines two otherwise unrelated contexts, ACME and DTN, when a protocol term applies to one of those areas and is used in the other its name is prefixed with either "ACME" or "DTN" respectively.
Thus within the ACME context the term is "DTN Node ID" while in the DTN context the name is just "Node ID".
</t>
<t>
In this document, several terms are shortened for the sake of terseness.
These terms are:
</t>
Expand All @@ -193,6 +197,30 @@ This is a shortened form of the full "ACME Node ID Validation Response Bundle".
It is a Bundle created by the BP agent managed by the ACME client to validate a Node ID claim.
</dd>
</dl>
<t>
Because this is an ACME document, the following DTN Bundle Protocol terms are defined here to clarify how they are used by this ACME identifier type and validation mechanism.
</t>
<dl>
<dt>Endpoint ID:</dt>
<dd>
An Endpoint ID is an identifier for the ultimate destination of a bundle, independent of any intermediate forwarding needed to reach that destination.
An endpoint can be a singleton (unicast) or not (anycast or multicast) so an Endpoint ID can also represent a single entity or a set of entities.
This is formally defined in <xref section="4.2.5.1" target="I-D.ietf-dtn-bpbis"/>.
</dd>
<dt>Node ID:</dt>
<dd>
A Node ID is a (not guaranteed unique) identifier for a specific node in a network in the form of a singleton Endpoint ID.
A single node can have any number of Node IDs but a typical (and expected) form of Node ID is the Administrative Endpoint ID (described below).
This is formally defined in <xref section="4.2.5.2" target="I-D.ietf-dtn-bpbis"/>.
</dd>
<dt>Administrative Endpoint ID:</dt>
<dd>
An Administrative Endpoint ID is unique for a node within a specific URI scheme.
Although any Node ID can be a valid bundle Source and Destination, the Administrative Endpoint ID is a minimum required Node ID for any node operating in a particular URI scheme.
For the "dtn" scheme this is the empty demux part and for the "ipn" scheme this is the service number zero.
These is formally defined under <xref section="4.2.5.1" target="I-D.ietf-dtn-bpbis"/>.
</dd>
</dl>
</section>
</section>
<section anchor="sec-acme-uri">
Expand Down Expand Up @@ -224,6 +252,19 @@ An identifier for the Node ID of "dtn://example/" would be formatted as:
"value": "dtn://example/"
}
</sourcecode>
<section anchor="sec-eid-uses">
<name>Subsets of Endpoint ID</name>
<t>
While the PKIX other name form of <tt>BundleEID</tt> can hold any Endpoint ID value, the certificate profile used by <xref target="I-D.ietf-dtn-tcpclv4"/> and supported by this ACME validation method in <xref target="sec-validate-nodeid"/> requires that the value hold a Node ID.
</t>
<t>
In addition to the narrowing of that certificate profile, this validation method requires that the client's BP agent responds to administrative records sent to the Node ID being validated.
This typically is limited to an Administrative Endpoint ID, but there is no prohibition on the administrative element of a BP node from receiving administrative records for, and sending records from, other Node IDs in order to support this validation method.
</t>
<t>
Neither that certificate profile nor this validation method support operating on non-singleton Endpoint IDs, but other validation methods could be defined to do so in order to support other certificate profiles.
</t>
</section>
</section>
<section anchor="sec-validate-nodeid">
<name>DTN Node ID Validation</name>
Expand Down Expand Up @@ -428,7 +469,6 @@ Each Challenge Bundle has parameters as listed here:
<dd>
The primary block flags <bcp14>SHALL</bcp14> indicate that the payload is an administrative record.
The primary block flags <bcp14>SHALL</bcp14> indicate that user application acknowledgement is requested; this flag distinguishes the Challenge Bundle from the Response Bundle.
The primary block flags <bcp14>MAY</bcp14> indicate that status reports are requested; such status can be helpful to troubleshoot routing issues.
</dd>
<dt>Destination EID:</dt>
<dd>
Expand Down Expand Up @@ -497,7 +537,6 @@ The challenge payload contains a <tt>token-bundle</tt> meeting the definition in
</ul>
<t>
Any of the failures above <bcp14>SHALL</bcp14> cause the challenge bundle to be deleted and otherwise ignored by the BP agent.
The BP agent <bcp14>MAY</bcp14> send status reports about the deletion if allowed by security policy.
</t>
</section>
</section>
Expand All @@ -514,7 +553,6 @@ Each Response Bundle has parameters as listed here:
<dd>
The primary block flags <bcp14>SHALL</bcp14> indicate that the payload is an administrative record.
The primary block flags <bcp14>SHALL NOT</bcp14> indicate that user application acknowledgement is requested; this flag distinguishes the Response Bundle from the Challenge Bundle.
The primary block flags <bcp14>MAY</bcp14> indicate that status reports are requested; such status can be helpful to troubleshoot routing issues.
</dd>
<dt>Destination EID:</dt>
<dd>
Expand Down Expand Up @@ -650,6 +688,7 @@ When a bundle security certificate is issued based on a validated Node ID SAN, t
A single bundle security CSR <bcp14>MAY</bcp14> contain a mixed set of SAN claims, including combinations of "ip", "dns", and "bundleEID" claims.
There is no restriction on how a certificate combines these claims, but each claim <bcp14>SHALL</bcp14> be validated by an ACME server to issue such a certificate as part of an associated ACME order.
This is no different than the existing behavior of <xref target="RFC8555"/> but is mentioned here to make sure that CA policy handles such situations; especially related to validation failure of an identifier in the presence of multiple identifiers.
The initial "ip" validations are defined in <xref target="RFC8738"/> and initial "dns" validations are defined in <xref target="RFC8555"/> and <xref target="RFC8737"/>.
The specific use case of <xref target="I-D.ietf-dtn-tcpclv4"/> allows, and for some network policies requires, that a certificate authenticate both the DNS name of an entity as well as the Node ID of the entity.
</t>
</section>
Expand Down Expand Up @@ -858,15 +897,6 @@ Within the "Bundle Protocol" registry <xref target="IANA-BP"/>, the following en
</table>
</section>
</section>
<section anchor="sec-doc-ack">
<name>Acknowledgments</name>
<t>
This specification is based on DTN use cases related to PKIX certificate issuance.
</t>
<t>
The workflow and terminology of this validation method was originally copied from the work of Alexey Melnikov in <xref target="RFC8823"/>.
</t>
</section>
</middle>
<back>
<references>
Expand Down Expand Up @@ -929,26 +959,26 @@ The workflow and terminology of this validation method was originally copied fro
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5050.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8737.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8738.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8823.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dtn-bibect.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dtn-tcpclv4.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.sipos-dtn-udpcl.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.sipos-bpv7-admin-iana.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.bsipos-dtn-bpsec-cose.xml"/>
<reference anchor="github-dtn-demo-agent" target="https://github.com/BSipos-RKF/dtn-demo-agent/">
<reference anchor="github-dtn-demo-agent" target="https://github.com/BrianSipos/dtn-demo-agent/">
<front>
<title>Python implementation of basic BPv7-related protocols</title>
<author fullname="Brian Sipos" initials="B." surname="Sipos">
<organization abbrev="RKF Engineering">RKF Engineering Solutions, LLC</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="github-dtn-wireshark" target="https://github.com/BSipos-RKF/dtn-wireshark/">
<reference anchor="github-dtn-wireshark" target="https://github.com/BrianSipos/dtn-wireshark/">
<front>
<title>Wireshark Dissectors for BPv7-related Protocols</title>
<author fullname="Brian Sipos" initials="B." surname="Sipos">
<organization abbrev="RKF Engineering">RKF Engineering Solutions, LLC</organization>
</author>
<date/>
</front>
Expand Down Expand Up @@ -1029,7 +1059,7 @@ This challenge requires that the ACME client respond within a 60 second time win
0, / CRC type: none /
[1, "//acme-client/"], / destination /
[1, "//acme-server/"], / source /
[1, "//acme-server/"], / report-to /
[1, 0], / report-to: none /
[1000000, 0], / timestamp: 2000-01-01T00:16:40+00:00 /
60000 / lifetime: 60s /
],
Expand All @@ -1041,7 +1071,7 @@ This challenge requires that the ACME client respond within a 60 second time win
&lt;&lt;[ / type-specific data /
0xFFFF, / record-type-code /
{ / record-content /
1: b64'dDtaviYTPUWFS3NK37YWfQ' / id-chal /
1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle /
}
]&gt;&gt;
Expand Down Expand Up @@ -1085,8 +1115,8 @@ This response indicates that there is 30 seconds remaining in the response time
&lt;&lt;[ / block-type-specific data /
0xFFFF, / record-type-code /
{ / record-content /
1: b64'dDtaviYTPUWFS3NK37YWfQ' / id-chal /
2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle /
1: b64'dDtaviYTPUWFS3NK37YWfQ', / id-chal /
2: b64'p3yRYFU4KxwQaHQjJ2RdiQ', / token-bundle /
3: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew'
/ key auth. digest /
}
Expand All @@ -1097,5 +1127,14 @@ This response indicates that there is 30 seconds remaining in the response time
</figure>
</section>
</section>
<section anchor="sec-doc-ack" numbered="false">
<name>Acknowledgments</name>
<t>
This specification is based on DTN use cases related to PKIX certificate issuance.
</t>
<t>
The workflow and terminology of this validation method was originally copied from the work of Alexey Melnikov in <xref target="RFC8823"/>.
</t>
</section>
</back>
</rfc>

0 comments on commit 22d5be7

Please sign in to comment.