randy/draft-9092update
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

-05 published with major rewrite of sec 5 by russ

Browse source
This commit is contained in:
Randy Bush 2023-10-15 15:15:21 -07:00
parent 862d1daf03
commit cb3e88d38d
1 changed files with 189 additions and 194 deletions
Download patch file Download diff file Expand all files Collapse all files

325
draft-ietf-opsawg-9092-update.xml
View file

@ -8,7 +8,7 @@
<?rfc compact="yes"?> <?rfc compact="yes"?>
<?rfc subcompact="no"?> <?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-opsawg-9092-update-04" <rfc category="std" docName="draft-ietf-opsawg-9092-update-05"
submissionType="IETF" consensus="true" ipr="trust200902" submissionType="IETF" consensus="true" ipr="trust200902"
obsoletes="9092" version="2" > obsoletes="9092" version="2" >
@ -413,178 +413,182 @@
<section anchor="auth" numbered="true" toc="default"> <section anchor="auth" numbered="true" toc="default">
<name>Authenticating Geofeed Data (Optional)</name> <name>Authenticating Geofeed Data (Optional)</name>
<t> <t>
The question arises whether a particular geofeed <xref The question arises whether a particular geofeed <xref
target="RFC8805" format="default"/> data set is valid, i.e., is target="RFC8805"/> data set is valid, i.e., is authorized by the
authorized by the "owner" of the IP address space and is "owner" of the IP address space and is authoritative in some
authoritative in some sense. The inetnum: that points to the sense. The inetnum: that points to the geofeed <xref
geofeed <xref target="RFC8805" format="default"/> file provides target="RFC8805"/> file provides some assurance. Unfortunately,
some assurance. Unfortunately, the RPSL in some repositories is the RPSL in some repositories is weakly authenticated at best.
weakly authenticated at best. An approach where RPSL was signed An approach where RPSL was signed per <xref target="RFC7909"/>
per <xref target="RFC7909" format="default"/> would be good, would be good, except it would have to be deployed by all RPSL
except it would have to be deployed by all RPSL registries, and registries, and there is a fair number of them.
there is a fair number of them.
</t>
<t>
A single optional authenticator MAY be appended
to a geofeed <xref target="RFC8805" format="default"/> file. It
is a digest of the main body of the file signed by the private
key of the relevant RPKI certificate for a covering address
range. One needs a format that bundles the relevant RPKI
certificate with the signature of the geofeed text.
</t>
<t>
The canonicalization procedure converts the data from their
internal character representation to the UTF-8 <xref
target="RFC3629" format="default"/> character encoding, and the
&lt;CRLF&gt; sequence MUST be used to denote the
end of a line of text. A blank line is represented solely by
the &lt;CRLF&gt; sequence. For robustness, any non-printable
characters MUST NOT be changed by
canonicalization. Trailing blank lines MUST NOT
appear at the end of the file. That is, the file must not end
with multiple consecutive &lt;CRLF&gt; sequences. Any
end-of-file marker used by an operating system is not considered
to be part of the file content. When present, such end-of-file
markers MUST NOT be processed by the digital
signature algorithm.
</t>
<t>
Should the authenticator be syntactically incorrect per the
above, the authenticator is invalid.
</t> </t>
<t> <t>
Borrowing detached signatures from <xref target="RFC5485" The remainder of this section specifies an optional
format="default"/>, after file canonicalization, the authenticator for the geofeed data set that follows the Signed
Cryptographic Message Syntax (CMS) <xref target="RFC5652" Object Template for the Resource Public Key Infrastructure
format="default"/> would be used to create a detached (RPKI) <xref target="RFC6488"/>.
DER-encoded signature that is then padded BASE64 encoded (as per
<xref target="RFC4648" sectionFormat="of" section="4"
format="default"/>) and line wrapped to 72 or fewer characters.
The same digest algorithm MUST be used for
calculating the message digest on content being signed, which is
the geofeed file, and for calculating the message digest on the
SignerInfo SignedAttributes <xref target="RFC8933"
format="default"/>. The message digest algorithm identifier
MUST appear in both the SignedData
DigestAlgorithmIdentifiers and the SignerInfo
DigestAlgorithmIdentifier <xref target="RFC5652"
format="default"/>.
</t> </t>
<t>
A single optional authenticator MAY be appended to a geofeed
<xref target="RFC8805"/> file. It is a digest of the main body
of the file signed by the private key of the relevant RPKI
certificate for a covering address range. The following format
bundles the relevant RPKI certificate with a signature over the
geofeed text.
</t>
<t>
The canonicalization procedure converts the data from their
internal character representation to the UTF-8 <xref
target="RFC3629"/> character encoding, and the &lt;CRLF&gt;
sequence MUST be used to denote the end of each line of text. A
blank line is represented solely by the &lt;CRLF&gt; sequence.
For robustness, any non-printable characters MUST NOT be changed
by canonicalization. Trailing blank lines MUST NOT appear at
the end of the file. That is, the file must not end with
multiple consecutive &lt;CRLF&gt; sequences. Any end-of-file
marker used by an operating system is not considered to be part
of the file content. When present, such end-of-file markers
MUST NOT be covered by the digital signature.
</t>
<t>
If the authenticator is not in the canonical form described above,
then, the authenticator is invalid.
</t>
<t>
Borrowing detached signatures from <xref target="RFC5485"/>,
after file canonicalization, the Cryptographic Message Syntax
(CMS) <xref target="RFC5652"/> is used to create a detached
DER-encoded signature that is then Base64 encoded with padding
(as defined in Section 4 of <xref target="RFC4648"/>) and line
wrapped to 72 or fewer characters. The same digest algorithm
MUST be used for calculating the message digest of the content
being signed, which is the geofeed file, and for calculating the
message digest on the SignerInfo SignedAttributes <xref
target="RFC8933"/>. The message digest algorithm identifier
MUST appear in both the CMS SignedData
DigestAlgorithmIdentifiers and the SignerInfo
DigestAlgorithmIdentifier <xref target="RFC5652"/>. The RPKI
certificate covering the geofeed inetnum: object's address range
is included in the CMS SignedData certificates field <xref
target="RFC5652"/>.
</t>
<t> <t>
The address range of the signing certificate MUST cover all The address range of the signing certificate MUST cover all
prefixes on the geofeed file it signs. The certificate MUST NOT prefixes in the signed geofeed file. The signing certificate
include the Autonomous System Identifier Delegation certificate MUST NOT include the Autonomous System Identifier Delegation
extension <xref target="RFC3779"/>. certificate extension <xref target="RFC3779"/>.
</t> </t>
<t>
As with many other RPKI signed objects, the IP Address
Delegation certificate extension MUST NOT use the "inherit"
capability defined in Section 2.2.3.5 of <xref
target="RFC3779"/>. An IP Address Delegation extension using
"inherit" would complicate processing. The implementation would
have to build the certification path from the end-entity to the
trust anchor, then validate the path from the trust anchor to
the end-entity, and then the parameter would have to be
remembered when the validated public key was used to validate a
signature on a CMS object. Having to remember things from
certification path validation for use with CMS object processing
is too hard. And, the certificates do not get that much bigger
by repeating the information.
</t>
<t> <t>
An address range A "covers" address range B if the range of B is An address range A "covers" address range B if the range of B is
identical to or a subset of A. "Address range" is used here identical to or a subset of A. "Address range" is used here
because inetnum: objects and RPKI certificates need not align on because inetnum: objects and RPKI certificates need not align on
Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/> Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/>
prefix boundaries, while those of the lines in a geofeed file prefix boundaries, while those of the lines in a geofeed file do
do. align.
</t> </t>
<t> <t>
As the signer specifies the covered RPKI resources relevant to The CA MUST sign only one geofeed with a particular generated
the signature, the RPKI certificate covering the inetnum: private key and MUST generate a new key pair for each new
object's address range is included in the <xref target="RFC5652" version of the geofeed. An associated EE certificate used in
format="default"/> CMS SignedData certificates field. this fashion is termed a "one-time- use" EE certificate (see
</t> Section 3 of <xref target="RFC6487"/>).
<t>
The CA MUST sign only one Geofeed with each generated private
key and MUST generate a new key pair for each new version of the
Geofeed. An associated EE certificate used in this fashion is
termed a "one-time-use" EE certificate (see Section 3 of
<xref target="RFC6487"/>).
</t> </t>
<t> <t>
Identifying the private key associated with the certificate and Identifying the private key associated with the certificate and
getting the department that controls the private key (which getting the department that controls the private key (which
might be trapped in a Hardware Security Module (HSM)) to sign might be stored in a Hardware Security Module (HSM)) to generate
the CMS blob is left as an exercise for the implementor. On the the CMS signature is left as an exercise for the implementor.
other hand, verifying the signature requires no complexity; the On the other hand, verifying the signature has no similar
certificate, which can be validated in the public RPKI, has the complexity; the certificate, which is validated in the public
needed public key. RPKI, contains the needed public key. The RPKI trust anchors
for the RIRs are expected to already be available to the party
The trust anchors for the RIRs are expected to already be performing signature validation. Validation of the CMS
available to the party performing signature validation. signature over the geofeed file involves:
Validation of the CMS signature on the geofeed file
involves:</t>
<ol spacing="normal" type="1"><li>
<t>
Obtaining the signer's certificate from the CMS SignedData
CertificateSet <xref target="RFC5652" format="default"/>. The
certificate SubjectKeyIdentifier extension <xref
target="RFC5280" format="default"/> MUST match
the SubjectKeyIdentifier in the CMS SignerInfo
SignerIdentifier <xref target="RFC5652" format="default"/>.
If the key identifiers do not match, then validation
MUST fail.</t>
<t>
Validation of the signer's certificate MUST
ensure that it is part of the current <xref target="RFC6486"
format="default"/> manifest and that the resources are covered
by the RPKI certificate.
</t> </t>
<ol spacing="normal" type="1">
<li>
Obtain the signer's certificate from the CMS SignedData
CertificateSet <xref target="RFC5652"/>. The certificate
SubjectKeyIdentifier extension <xref target="RFC5280"/> MUST
match the SubjectKeyIdentifier in the CMS SignerInfo
SignerIdentifier <xref target="RFC5652"/>. If the key
identifiers do not match, then validation MUST fail.
</li> </li>
<li> <li>
Constructing the certification path for the signer's Validation of the signer's certificate MUST ensure that it is
certificate. All of the needed certificates are expected to part of the current <xref target="RFC6486"/> manifest and that
be readily available in the RPKI repository. The all resources are covered by the RPKI certificate.
certification path MUST be valid according to
the validation algorithm in <xref target="RFC5280"
format="default"/> and the additional checks specified in
<xref target="RFC3779" format="default"/> associated with the
IP Address Delegation certificate extension and the Autonomous
System Identifier Delegation certificate extension. If
certification path validation is unsuccessful, then validation
MUST fail.
</li> </li>
<li> <li>
Validating the CMS SignedData as specified in <xref Construct the certification path for the signer's certificate.
target="RFC5652" format="default"/> using the public key from All of the needed certificates are expected to be readily
the validated signer's certificate. If the signature available in the RPKI repository. The certification path MUST
validation is unsuccessful, then validation be valid according to the validation algorithm in <xref
MUST fail. target="RFC5280"/> and the additional checks specified in
<xref target="RFC3779"/> associated with the IP Address
Delegation certificate extension and the Autonomous System
Identifier Delegation certificate extension. If certification
path validation is unsuccessful, then validation MUST fail.
</li> </li>
<li> <li>
Verifying that the IP Address Delegation certificate extension Validate the CMS SignedData as specified in <xref
<xref target="RFC3779" format="default"/> covers all of the target="RFC5652"/> using the public key from the validated
address ranges of the geofeed file. If all of the address signer's certificate. If the signature validation is
ranges are not covered, then validation MUST unsuccessful, then validation MUST fail.
fail. </li>
<li>
Confirm that the eContentType object identifier (OID) is
id-ct-geofeedCSVwithCRLF (1.2.840.113549.1.9.16.1.47). This
OID MUST appear within both the eContentType in the
encapContentInfo object and the ContentType signed attribute
in the signerInfo object (see <xref target="RFC6488"/>).
</li>
<li>
Verify that the IP Address Delegation certificate extension
<xref target="RFC3779"/> covers all of the address ranges of
the geofeed file. If all of the address ranges are not
covered, then validation MUST fail.
</li> </li>
</ol> </ol>
<t> <t>
All of these steps MUST be successful to consider All of the above steps MUST be successful to consider the
the geofeed file signature as valid. geofeed file signature as valid.
</t>
<t>
As the signer specifies the covered RPKI resources relevant to the
signature, the RPKI certificate covering the inetnum: object's address
range is included in the CMS SignedData certificates field <xref
target="RFC5652" format="default"/>.
</t>
<t>
An IP Address Delegation extension using "inherit" would
complicate processing. The implementation would have to build
the certification path from the end-entity to the trust anchor,
then validate the path from the trust anchor to the end-entity,
and then the parameter would have to be remembered when the
validated public key was used to validate a signature on a CMS
object. Having to remember things from certification path
validation for use with CMS object processing is too hard. And,
the certificates do not get that much bigger by repeating the
information.
</t>
<t>
Therefore an extension using "inherit" MUST NOT be used. This
is consistent with other RPKI signed objects.
</t> </t>
<t> <t>
Identifying the private key associated with the certificate and Identifying the private key associated with the certificate and
getting the department with the Hardware Security Module (HSM) getting the department with the Hardware Security Module (HSM)
@ -593,11 +597,11 @@
complexity; the certificate, which can be validated in the complexity; the certificate, which can be validated in the
public RPKI, has the needed public key. public RPKI, has the needed public key.
</t> </t>
<t> <t>
The appendix MUST be hidden as a series of "#" comments at the The authenticator MUST be hidden as a series of "#" comments at the
end of the geofeed file. The following is a cryptographically end of the geofeed file. The following simple example is
incorrect, albeit simple, example. A correct and full example is cryptographically incorrect:
in <xref target="example" format="default"/>.
</t> </t>
<sourcecode type=""><![CDATA[ <sourcecode type=""><![CDATA[
# RPKI Signature: 192.0.2.0 - 192.0.2.255 # RPKI Signature: 192.0.2.0 - 192.0.2.255
@ -608,30 +612,24 @@
# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk= # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
# End Signature: 192.0.2.0 - 192.0.2.255 # End Signature: 192.0.2.0 - 192.0.2.255
]]></sourcecode> ]]></sourcecode>
<t> <t>
The signature does not cover the signature lines. A correct and full example is in Appendix A.
</t> </t>
<t> <t>
The bracketing "# RPKI Signature:" and "# End Signature:" The CMS signature does not cover the signature lines.
MUST be present following the model as shown.
Their IP address range MUST match that of the
inetnum: URL followed to the file.
</t> </t>
<t> <t>
<xref target="RFC9323" format="default"/> describes The bracketing "# RPKI Signature:" and "# End Signature:" MUST
and provides code for a CMS profile for be present as shown in the example. The RPKI Signature's IP
a general purpose listing of checksums (a "checklist") for use with address range MUST match that of the geofeed URL in the inetnum:
the Resource Public Key Infrastructure (RPKI). It provides usable, that points to the geofeed file.
albeit complex, code to sign geofeed files.
</t>
<t>
<xref target="I-D.ietf-sidrops-rpki-rta" format="default"/> describes
a CMS profile for a general purpose Resource Tagged Attestation (RTA)
based on the RPKI. While this is expected to become applicable in the
long run, for the purposes of this document, a self-signed root trust
anchor is used.
</t> </t>
</section> </section>
<section anchor="ops" numbered="true" toc="default"> <section anchor="ops" numbered="true" toc="default">
<name>Operational Considerations</name> <name>Operational Considerations</name>
@ -832,8 +830,6 @@
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-sidrops-rpki-rta" to="RPKI-RTA"/>
<references title="Normative References"> <references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?> <?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2622.xml"?> <?rfc include="reference.RFC.2622.xml"?>
@ -849,6 +845,7 @@
<?rfc include="reference.RFC.6481.xml"?> <?rfc include="reference.RFC.6481.xml"?>
<?rfc include="reference.RFC.6486.xml"?> <?rfc include="reference.RFC.6486.xml"?>
<?rfc include="reference.RFC.6487.xml"?> <?rfc include="reference.RFC.6487.xml"?>
<?rfc include="reference.RFC.6488.xml"?>
<?rfc include="reference.RFC.8805.xml"?> <?rfc include="reference.RFC.8805.xml"?>
<?rfc include="reference.RFC.8933.xml"?> <?rfc include="reference.RFC.8933.xml"?>
</references> </references>
@ -864,8 +861,6 @@
<?rfc include="reference.RFC.7909.xml"?> <?rfc include="reference.RFC.7909.xml"?>
<?rfc include="reference.RFC.9082.xml"?> <?rfc include="reference.RFC.9082.xml"?>
<?rfc include="reference.RFC.9092.xml"?> <?rfc include="reference.RFC.9092.xml"?>
<?rfc include="reference.RFC.9323.xml"?>
<?rfc include="reference.I-D.ietf-sidrops-rpki-rta.xml"?>
<reference anchor="RIPE81" target="https://www.ripe.net/publications/docs/ripe-081"> <reference anchor="RIPE81" target="https://www.ripe.net/publications/docs/ripe-081">
<front> <front>
<title>Representation Of IP Routing Policies In The RIPE Database</title> <title>Representation Of IP Routing Policies In The RIPE Database</title>