some hacks in response to secdir

This commit is contained in:
Randy Bush 2025-03-26 13:02:22 -07:00
parent 44a7c16f5f
commit c67a751d13

View file

@ -453,12 +453,12 @@
Transmission Sequence Number informs the receiver that it is the
same PDU.</t>
<t>The L3DL OPEN PDU contains an algorithm identifier, a key, and a
L3DL certificate, which can be used to verify signatures on
subsequent PDUs. This document describes two methods of key
generation and signing for use by L3DL, Trust On First Use (TOFU)
and a PKI-based mechanism to provide authentication as well as
session integrity. See <xref target="sigtypes"/>.</t>
<t>The L3DL OPEN PDU contains an algorithm identifier, and a key
which can be used to verify signatures on subsequent PDUs. This
document describes two methods of key generation and signing for use
by L3DL, Trust On First Use (TOFU) and a PKI-based mechanism to
provide authentication as well as session integrity. See <xref
target="sigtypes"/>.</t>
<!--
protocol "Version:8,Transmission Sequence Number:16,L:1,Datagram Number:23,Datagram Length:16,Checksum:32,Payload...:32"
@ -1858,12 +1858,11 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<section anchor="sigtypes" title="Signature Types">
<t>The L3DL OPEN PDU contains an algorithm identifier, a key, and
a L3DL certificate, which can be used to verify signatures on
subsequent PDUs. This document describes two methods of key
generation and signing for use by L3DL, Trust On First Use (TOFU)
and a PKI-based mechanism to provide authentication as well as
session integrity.</t>
<t>The L3DL OPEN PDU contains an algorithm identifier and a key
which can be used to verify signatures on subsequent PDUs. This
document describes two methods of key generation and signing for
use by L3DL, Trust On First Use (TOFU) and a PKI-based mechanism
to provide authentication as well as session integrity.</t>
<t>The Key in the OPEN PDU SHOULD be the public key of an asymmetric
key pair. The sender signs with the private key, of course. The
@ -1928,10 +1927,8 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>
Compose the PDU, with all fields including "Sig Algo" and
"Signature Length" set, but omitting the trailing
"Signature" field itself. The Certificate Length should
be zero and the Certificate field should be empty. This
is the "message to be signed" for purposes of the
signature algorithm.
"Signature" field itself. This is the "message to be
signed" for purposes of the signature algorithm.
</t>
<t>
@ -2108,13 +2105,13 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>
Generating and signing the OPEN PDU with the PKI method is
almost the same as in <xref target="tofu-pdu-signing"/>. The
only difference is that the PKI method MUST supply the
appropriate certificate in the Certificate field.
only difference is that the PKI method uses the certificate
supplied out of band.
</t>
<t>
Note that the Auth Type field applies to both the Key and
Certificate fields. That is: the certificate uses the same
Note that the Auth Type field applies to the Key field and the
supplied certificate. That is: the certificate uses the same
certificate suite as the session keys, L3DL does not support
cross-algorithm-suite certification.
</t>
@ -2131,11 +2128,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>
After extracting the Key field from the PDU but before
verifying the Signature, extract the Certificate field and
verfiy that the Certificate is a valid signature of the Key
field, according to the rules for the signature suite
specified by Auth Type. If this step fails, handle as in
<xref target="tofu-open-verifying"/>.
verifying the Signature, verfiy that the Certificate is a
valid signature of the Key field, according to the rules for
the signature suite specified by Auth Type. If this step
fails, handle as in <xref target="tofu-open-verifying"/>.
</t>
</section>
@ -2159,7 +2155,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>
Require TOFU: sender MUST supply key and receiver MUST
check, but L3DL certificates not needed and ignored if sent.
check, but L3DL certificates not needed and are ignored.
</t>
<t>
@ -2168,8 +2164,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
</t>
<t>
Require PKI: sender MUST supply key and L3DL certificate,
receiver MUST check signature and verify the L3DL certificate.
Require PKI: sender MUST supply key and and L3DL certificate
MUST be supplied out of band, and the receiver MUST check
the signature and verify the L3DL certificate.
</t>
</list>
@ -2329,7 +2326,7 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
covering the payload.</t>
<t>The PKI method offers assurance that the L3DL certificate, and
hence the public key, provided in the OPEN PDU are authorized
hence the public key provided in the OPEN PDU, are authorized
by a central authority, e.g. the network's security team. The
onward assurance of talking to the same peer and data integrity are
the same as in the TOFU method.</t>
@ -2343,6 +2340,12 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n)
<t>The REKEY PDU is open to abuse to create a signature algorithm
downgrade attack.</t>
<t>If L3DL is used in a WAN deployment, as opposed to tightly
controlled data center, the use SHOULD be restricted to iBGP peers
and/or eBGP confederations within the operator's scope of trust.
And, because of tapping and interception threats, the PKI-based
authourization mechanism SHOULD be used.</t>
</section>
<section anchor="iana" title="IANA Considerations">