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 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"
obsoletes="9092" version="2" >
@ -413,191 +413,195 @@
<section anchor="auth" numbered="true" toc="default">
<name>Authenticating Geofeed Data (Optional)</name>
<t>
The question arises whether a particular geofeed <xref
target="RFC8805" format="default"/> data set is valid, i.e., is
authorized by the "owner" of the IP address space and is
authoritative in some sense. The inetnum: that points to the
geofeed <xref target="RFC8805" format="default"/> file provides
some assurance. Unfortunately, the RPSL in some repositories is
weakly authenticated at best. An approach where RPSL was signed
per <xref target="RFC7909" format="default"/> would be good,
except it would have to be deployed by all RPSL registries, and
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.
The question arises whether a particular geofeed <xref
target="RFC8805"/> data set is valid, i.e., is authorized by the
"owner" of the IP address space and is authoritative in some
sense. The inetnum: that points to the geofeed <xref
target="RFC8805"/> file provides some assurance. Unfortunately,
the RPSL in some repositories is weakly authenticated at best.
An approach where RPSL was signed per <xref target="RFC7909"/>
would be good, except it would have to be deployed by all RPSL
registries, and there is a fair number of them.
</t>
<t>
Borrowing detached signatures from <xref target="RFC5485"
format="default"/>, after file canonicalization, the
Cryptographic Message Syntax (CMS) <xref target="RFC5652"
format="default"/> would be used to create a detached
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"/>.
The remainder of this section specifies an optional
authenticator for the geofeed data set that follows the Signed
Object Template for the Resource Public Key Infrastructure
(RPKI) <xref target="RFC6488"/>.
</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
available to the party performing signature validation.
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>
</li>
<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>
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>
Constructing the certification path for the signer's
certificate. All of the needed certificates are expected to
be readily available in the RPKI repository. The
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>
Validating the CMS SignedData as specified in <xref
target="RFC5652" format="default"/> using the public key from
the validated signer's certificate. If the signature
validation is unsuccessful, then validation
MUST fail.
</li>
<li>
Verifying that the IP Address Delegation certificate extension
<xref target="RFC3779" format="default"/> covers all of the
address ranges of the geofeed file. If all of the address
ranges are not covered, then validation MUST
fail.
</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>
Validation of the signer's certificate MUST ensure that it is
part of the current <xref target="RFC6486"/> manifest and that
all resources are covered by the RPKI certificate.
</li>
<li>
Construct the certification path for the signer's certificate.
All of the needed certificates are expected to be readily
available in the RPKI repository. The certification path MUST
be valid according to the validation algorithm in <xref
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>
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>
<t>
All of these steps MUST be successful to consider
the geofeed file signature as valid.
All of the above steps MUST be successful to consider the
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"/>.
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>
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>
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"/>.
The authenticator MUST be hidden as a series of "#" comments at the
end of the geofeed file. The following simple example is
cryptographically incorrect:
</t>
<sourcecode type=""><![CDATA[
# RPKI Signature: 192.0.2.0 - 192.0.2.255
@ -608,30 +612,24 @@
# O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
# End Signature: 192.0.2.0 - 192.0.2.255
]]></sourcecode>
<t>
The signature does not cover the signature lines.
A correct and full example is in Appendix A.
</t>
<t>
The bracketing "# RPKI Signature:" and "# End Signature:"
MUST be present following the model as shown.
Their IP address range MUST match that of the
inetnum: URL followed to the file.
The CMS signature does not cover the signature lines.
</t>
<t>
<xref target="RFC9323" format="default"/> describes
and provides code for a CMS profile for
a general purpose listing of checksums (a "checklist") for use with
the Resource Public Key Infrastructure (RPKI). It provides usable,
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>
The bracketing "# RPKI Signature:" and "# End Signature:" MUST
be present as shown in the example. The RPKI Signature's IP
address range MUST match that of the geofeed URL in the inetnum:
that points to the geofeed file.
</t>
</section>
<section anchor="ops" numbered="true" toc="default">
<name>Operational Considerations</name>
@ -832,8 +830,6 @@
</middle>
<back>
<displayreference target="I-D.ietf-sidrops-rpki-rta" to="RPKI-RTA"/>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2622.xml"?>
@ -849,6 +845,7 @@
<?rfc include="reference.RFC.6481.xml"?>
<?rfc include="reference.RFC.6486.xml"?>
<?rfc include="reference.RFC.6487.xml"?>
<?rfc include="reference.RFC.6488.xml"?>
<?rfc include="reference.RFC.8805.xml"?>
<?rfc include="reference.RFC.8933.xml"?>
</references>
@ -864,8 +861,6 @@
<?rfc include="reference.RFC.7909.xml"?>
<?rfc include="reference.RFC.9082.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">
<front>
<title>Representation Of IP Routing Policies In The RIPE Database</title>