some hacks in response to secdir
This commit is contained in:
parent
44a7c16f5f
commit
c67a751d13
1 changed files with 32 additions and 29 deletions
|
|
@ -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">
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue