Richard,
Thanks for thinking (in great depth) about the potential security
implications of
SKI collisions in BGPsec.
In the general case of a PKI, collisions of SKI values are not security
relevant.
The SKI MAY be used in path discovery, but the intent was to limit its
use to
quickly finding the right CA cert when multiple CA certs appear in the same
directory entry. (Specifically, one looks at the directory entry for the CA
specified as the Issuer of the cert for which a path is being
constructed. if
there is more than one CA cert in that entry, one can compare the AKI in the
target cert against the SKI values in each of the candidate parent CA certs.
The alternative is to try verifying the signature on the target cert
using each of the
public keys in the candidate parent certs. So, SKI/AKI matching is an
optional
optimization.) In the RPKI (ignoring BGPsec for the moment) this is still
how the SKI is to be used, and thus the only problem that might arise if an
INR holder created a lot of (CA) certs with the same SKI value (but
different keys)
is that the optimization would fail, and the RP would have to revert to the
"check the signature with each public key" fallback.
In BGPsec, the signature block carries an SKI and that value is used to
search for the
right key to use when verifying the signature on a signature segment.
Each signature
segment aligns with a secure path segment entry. The validation
algorithm described in
Section 5.2 of te BGPsec spec says that one queries a router cert
database containing
triples of (ASN, SKI, public key). Each query uses the ASN as the first
lookup key, then
it uses the SKI to locate the right key, if there is more than one for
the AS. This
is analogous to how the SKI is used in a traditional PKI, i.e., the SKI
is used to
speed up the process in case there are multiple public keys for the same
AS. (The algorithm
is not quite the same here, because an SKI match is required, but the
security
implications are the same.) Thus, while there is no need for SKIs to be
globally
unique, SKI collisions for router certs for a single AS could degrade
the router cert
lookup process.
Since we want a router to be able to quickly locate the right cert, it
does behoove
us to avoid the potential attack you noted. There is no easy way to
change the SKI
computation algorithm in a cert and signal that to RPs. This is an
oversight in the
X.509 design, but one that does not seem especially problematic in the
normal PKI
context. So mandating use of a different hash alg for SKI/AKI
computation is not
very attractive. In the BGPsec/RPKI our environment we could impose a
requirement
on RPs to check router certs to verify the criteria you cited, i.e., no
two router
certs for the same AS# are allowed have the same SKI and different
public keys.
I think this is a simple, additional check to add to the router cert
profile I-D.
Thanks for paying such careful attention to this!
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
