At IETF 70, Geoff and I agreed to put together a concrete proposal for
how multiple signatures on a ROA would work.
The attached file outlines our proposed changes to
draft-ietf-sidr-roa-format.
Comments, suggestions or clarifying questions would greatly appreciated.
- Matt Lepinski
Multiple Signatures on a ROA
High Level Overview of the Problem and the Proposed Solution:
-------------------------------------------------------------
Consider an ISP that wants to authorize an AS to advertise an aggregate
prefix, but no single certificate covers the aggregate prefix. (E.g., an
ISP has a resource certificate for 10.0/16 and another for 10.1/16, and
wants to authorize an AS to advertise 10.0/15.) In the architecture
currently described by draft- ietf-sidr-arch and draft-ietf-sidr-roa-
format, there is no way to construct a single ROA that authorizes the
advertisement of the aggregate prefix. This issue was discussed at the
SIDR meeting at IETF 70 in Vancouver. (For more information see:
http://www3.ietf.org/proceedings/07dec/slides/sidr-2.pdf and
http://www3.ietf.org/proceedings/07dec/minutes/sidr.txt )
The proposed solution is to alter the ROA format to allow for a ROA that
includes signatures from multiple signers. In essence, this provides a
way for a subject of the certificate containing 10.0/16 to state "I, as
the owner of 10.0/16, authorize AS 123 to advertise the aggregate prefix
10.0/15".
Note that the envisioned use-case for a multiple-signature ROA is when
all the EE certificates used to verify the signatures on a ROA are
controlled by the same administrative entity (e.g., a single ISP with
multiple certificates corresponding to multiple allocations). Clearly,
the proposed solution could also be made to work in a situation when the
EE certificates are controlled by distinct entities, but this introduces
administrative challenges that are beyond the scope of the current
discussion.
Proposed Syntax:
----------------
The proposed syntax is straightforward. A ROA is a CMS SignedData
object. As specified in RFC 3852, the SignerInfos attribute of a CMS
SignedData object can contain a list of SignerInfo objects. Instead of
restricting the SignerInfos attribute of a ROA to contain only a single
SignerInfo object, the proposed solution is to follow RFC 3852 and allow
for a list of SignerInfo objects.
Note that in addition to identifying the certificate of the signer, a
SignerInfo object also specifies the digest algorithm used to produce
the signature. Currently, we specify that the digest algorithm MUST be
SHA-256. However, if at some point in the future hash technology
improves and we decide to modify the ROA format to migrate to a new hash
function, then it would be use to produce a ROA with two SignerInfo
objects (both pointing to the same certificate but using different
digest algorithms). By now mandating support for multiple SignerInfo
objects, we ensure that such a future hash function migration can be
performed in a backwards compatible fashion.
Proposed Semantics:
-------------------
The proposed semantics is that a ROA is a valid authorization for the
specified AS to advertise the specified prefix if the valid signatures
correspond to address ranges whose union is the specified prefix. If the
valid signatures do not correspond to address ranges whose union is the
specified prefix, then the ROA is treated as invalid. (That is, all
invalid ROAs are treated the same regardless of whether or not they have
one or more valid signatures.)
Note that while overlapping address ranges is not considered normative
for this specification it is not precluded. In the degenerate case where
there are multiple signatures that correspond to the same address range,
then the authorization is only considered valid if all signatures are
valid.
The instructions for ROA validation in Section 3 of draft-ietf-sidr-roa-
format would then be changed to the following:
1. Verify that the ROA syntax complies with this specification.
2. For each SignerInfo object in the SignerInfos list, do the
following:
2.A Obtain an EE certificate that has a Subject Key Identifier
(SKI) that matches the sid field of the SignerInfo object.
This certificate may be obtained from the certificates field
of the SignedData object (if present), the resource PKI
repository system, or a local cache.
2.B Use the public key in the EE certificate to verify the
signature on the ROA.
2.C Verify that the EE certificate is a valid end-entity
certificate in the resource PKI by constructing a valid
certificate path to a trust anchor. (See
draft-ietf-sidr-res-certs for more details.)
2.D Verify that the EE certificate has an IP Address Delegation
extension [RFC3779]. Append the IP address prefix(es) to a
list of prefixes corresponding to verified signatures.
3. Compute the union of addresses in the list of prefixes
corresponding to verified signatures by aggregating adjacent
prefixes to the greatest possible extent. If this union exactly
matches the IP address prefix(es) in the ROA, then the ROA is
valid.
Note on the additional complexity introduced by this proposal:
Implementations must already have code that parses a SignerInfo object
and uses the EE certificate to verify the signature in the SignerInfo
object. This proposal would require looping through that code once for
each SignerInfo object, but this seems a small change. Additionally,
this proposal requires an implementation to create a list of prefixes
and then aggregate the prefixes to the greatest possible extent.
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
