randy/draft-l3dl-signing
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

some russ hacks

Browse source
This commit is contained in:
Randy Bush 2019-04-19 14:12:33 -07:00
parent e505fcb3d4
commit de18781808
1 changed files with 23 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

37
draft-ymbk-lsvr-l3dl-signing.xml
View file

@ -60,9 +60,10 @@
<t>The Layer 3 Discovery and Liveness protocol provides for the OPEN <t>The Layer 3 Discovery and Liveness protocol provides for the OPEN
PDU to contain a key which can be used to verify signatures on PDU to contain a key which can be used to verify signatures on
subsequent PDUs. This document describes two methods of key subsequent PDUs. This document describes two mechanisms based on
generation and signing for use by L3DL, Trust On First Use, AKA digital signatures, one that is Trust On First Use (TOFU), and one
TOFU, and PKI-based.</t> that uses X.509 certificates to provide authentication as well as
session integrity.</t>
</abstract> </abstract>
@ -93,17 +94,24 @@
provided in the OPEN PDU is used to verify the signatures on the provided in the OPEN PDU is used to verify the signatures on the
subsequent PDUs. The difference is how that key is generated.</t> subsequent PDUs. The difference is how that key is generated.</t>
<t>In the TOFU method the OPEN key is believed without question and <t>In the TOFU method the OPEN key is believed without question and
is used to verify all subsequent PDUs with the same Key Type.</t> is used to verify all subsequent PDUs from the same peer with the
same Key Type.</t>
<t>With the PKI-mechanism, an enrollment step is performed. The
public key and an identifier of the subject are put into a
certificate, which is signed by the trust anchor. In this way, the
relying party can be confident that the public key is under control
of the identified L3DL protocol entity.</t>
<t>In the PKI method the OPEN key MUST be verified against the trust <t>In the PKI method the OPEN key MUST be verified against the trust
anchor for the operational domain. It is then used to verify all anchor for the operational domain. It is then used to verify all
subsequent PDUs with the same Key Type.</t> subsequent PDUs from the same peer with the same Key Type.</t>
<t>The Key in the OPEN PDU SHOULD be the public half of an <t>The Key in the OPEN PDU SHOULD be the public key of an asymmetric
asymmetric key pair. The sender signs with the private key, of key pair. The sender signs with the private key, of course. The
course. The device sending the OPEN may use one key for all links, device sending the OPEN may use one key for all links, a different
a different key for each link, or some aggregation(s) thereof.</t> key for each link, or some aggregation(s) thereof.</t>
</section> </section>
@ -118,10 +126,11 @@
<section anchor="roll" title="NEWKEY, Key Roll"> <section anchor="roll" title="NEWKEY, Key Roll">
<t>Modern key management allows for agility in 'rolling' to a new <t>Modern key management allows for agility in 'rolling' to a new
key or even algorithm in case of key compromise or merely prudence. key or even algorithm in case of key expry, key compromise, or
Declaring a new key with an L3DL OPEN PDU would cause serious churn merely prudence. Declaring a new key with an L3DL OPEN PDU would
in topology as a new OPEN causes a withdraw of previously announced cause serious churn in topology as a new OPEN causes a withdraw of
encapsulations. Therefore, a gentler rekeying is needed.</t> previously announced encapsulations. Therefore, a gentler rekeying
is needed.</t>
<!-- <!--
protocol "Type = 8:8,Payload Length:16,New Key Type:8,New Key Length:16,New Key ...:40,Old Sig Type:8,Old Signature Length:16,Old Signature ...:40" protocol "Type = 8:8,Payload Length:16,New Key Type:8,New Key Length:16,New Key ...:40,Old Sig Type:8,Old Signature Length:16,Old Signature ...:40"