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

383
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,191 +413,195 @@
<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>
The address range of the signing certificate MUST cover all
prefixes on the geofeed file it signs. The certificate MUST NOT
include the Autonomous System Identifier Delegation certificate
extension <xref target="RFC3779"/>.
</t>
<t>
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
because inetnum: objects and RPKI certificates need not align on
Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/>
prefix boundaries, while those of the lines in a geofeed file
do.
</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 <xref target="RFC5652"
format="default"/> CMS SignedData certificates field.
</t>
<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>
Identifying the private key associated with the certificate and
getting the department that controls the private key (which
might be trapped in a Hardware Security Module (HSM)) to sign
the CMS blob is left as an exercise for the implementor. On the
other hand, verifying the signature requires no complexity; the
certificate, which can be validated in the public RPKI, has the
needed public key.
The trust anchors for the RIRs are expected to already be <t>
available to the party performing signature validation. A single optional authenticator MAY be appended to a geofeed
Validation of the CMS signature on the geofeed file <xref target="RFC8805"/> file. It is a digest of the main body
involves:</t> of the file signed by the private key of the relevant RPKI
<ol spacing="normal" type="1"><li> certificate for a covering address range. The following format
<t> bundles the relevant RPKI certificate with a signature over the
Obtaining the signer's certificate from the CMS SignedData geofeed text.
CertificateSet <xref target="RFC5652" format="default"/>. The </t>
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>
</li>
<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>
The address range of the signing certificate MUST cover all
prefixes in the signed geofeed file. The signing certificate
MUST NOT include the Autonomous System Identifier Delegation
certificate extension <xref target="RFC3779"/>.
</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>
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
because inetnum: objects and RPKI certificates need not align on
Classless Inter-Domain Routing (CIDR) <xref target="RFC4632"/>
prefix boundaries, while those of the lines in a geofeed file do
align.
</t>
<t>
The CA MUST sign only one geofeed with a particular 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>
Identifying the private key associated with the certificate and
getting the department that controls the private key (which
might be stored in a Hardware Security Module (HSM)) to generate
the CMS signature is left as an exercise for the implementor.
On the other hand, verifying the signature has no similar
complexity; the certificate, which is validated in the public
RPKI, contains the needed public key. The RPKI trust anchors
for the RIRs are expected to already be available to the party
performing signature validation. Validation of the CMS
signature over the geofeed file involves:
</t>
<ol spacing="normal" type="1">
<li> <li>
Constructing the certification path for the signer's Obtain the signer's certificate from the CMS SignedData
certificate. All of the needed certificates are expected to CertificateSet <xref target="RFC5652"/>. The certificate
be readily available in the RPKI repository. The SubjectKeyIdentifier extension <xref target="RFC5280"/> MUST
certification path MUST be valid according to match the SubjectKeyIdentifier in the CMS SignerInfo
the validation algorithm in <xref target="RFC5280" SignerIdentifier <xref target="RFC5652"/>. If the key
format="default"/> and the additional checks specified in identifiers do not match, then validation MUST fail.
<xref target="RFC3779" format="default"/> associated with the </li>
IP Address Delegation certificate extension and the Autonomous
System Identifier Delegation certificate extension. If <li>
certification path validation is unsuccessful, then validation Validation of the signer's certificate MUST ensure that it is
MUST fail. part of the current <xref target="RFC6486"/> manifest and that
</li> all resources are covered by the RPKI certificate.
</li>
<li>
Validating the CMS SignedData as specified in <xref <li>
target="RFC5652" format="default"/> using the public key from Construct the certification path for the signer's certificate.
the validated signer's certificate. If the signature All of the needed certificates are expected to be readily
validation is unsuccessful, then validation available in the RPKI repository. The certification path MUST
MUST fail. be valid according to the validation algorithm in <xref
</li> target="RFC5280"/> and the additional checks specified in
<li> <xref target="RFC3779"/> associated with the IP Address
Verifying that the IP Address Delegation certificate extension Delegation certificate extension and the Autonomous System
<xref target="RFC3779" format="default"/> covers all of the Identifier Delegation certificate extension. If certification
address ranges of the geofeed file. If all of the address path validation is unsuccessful, then validation MUST fail.
ranges are not covered, then validation MUST </li>
fail.
</li> <li>
Validate the CMS SignedData as specified in <xref
target="RFC5652"/> using the public key from the validated
signer's certificate. If the signature validation is
unsuccessful, then validation MUST 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>
</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>
<t> <t>
As the signer specifies the covered RPKI resources relevant to the Identifying the private key associated with the certificate and
signature, the RPKI certificate covering the inetnum: object's address getting the department with the Hardware Security Module (HSM)
range is included in the CMS SignedData certificates field <xref to sign the CMS blob is left as an exercise for the implementor.
target="RFC5652" format="default"/>. On the other hand, verifying the signature requires no
complexity; the certificate, which can be validated in the
public RPKI, has the needed public key.
</t> </t>
<t> <t>
An IP Address Delegation extension using "inherit" would The authenticator MUST be hidden as a series of "#" comments at the
complicate processing. The implementation would have to build end of the geofeed file. The following simple example is
the certification path from the end-entity to the trust anchor, cryptographically incorrect:
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>
Identifying the private key associated with the certificate and
getting the department with the Hardware Security Module (HSM)
to sign the CMS blob is left as an exercise for the implementor.
On the other hand, verifying the signature requires no
complexity; the certificate, which can be validated in the
public RPKI, has the needed public key.
</t>
<t>
The appendix MUST be hidden as a series of "#" comments at the
end of the geofeed file. The following is a cryptographically
incorrect, albeit simple, example. A correct and full example is
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>
<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>
</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>