From 48585b7d8eb84e0e32a1a8d0e0b104c4c8be8230 Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Wed, 17 Jul 2019 11:59:03 -0400 Subject: [PATCH] First pass on PDU signature and verification. --- draft-ymbk-lsvr-l3dl-signing.xml | 186 ++++++++++++++++++++++++++++++- 1 file changed, 185 insertions(+), 1 deletion(-) diff --git a/draft-ymbk-lsvr-l3dl-signing.xml b/draft-ymbk-lsvr-l3dl-signing.xml index 1955b50..e11a0ca 100644 --- a/draft-ymbk-lsvr-l3dl-signing.xml +++ b/draft-ymbk-lsvr-l3dl-signing.xml @@ -121,11 +121,187 @@
+ There are three parts to using a key: signing PDUs, verifying + the OPEN PDU, and verifying subsequent PDUs. + +
+ + All signed PDUs are generated in the same way: + + + + + Compose the PDU, with all fields including "Sig Type" and + "Signature Length" set, but omitting the trailing + "Signature" field itself. This is the "message to be + signed" for purposes of the signature algorithm. + + + + Generate the signature as specified for the chosen signature + suite, using the private member of the asymmetric key pair. + In general this will involve first hashing the "message to + be signed" then signing the hash, but the precise details + may vary with the specific algorithm. The result will be a + sequence of octets, the length of which MUST be equal to the + setting of the "Signature Length" field. + + + + Construct the complete message by appending the signature + octets to the otherwise complete message composed above. + + + + + + In the case of the OPEN PDU, the message to be signed will + include the public member of the asymmetric keypair, but as + far as the signature algorithm is concerned that's just + payload, no different from any other PDU content. + +
+
+ + + The process for verifying an OPEN PDU is slightly different + from the process for verifying other PDU types, because the + OPEN PDU also establishes the session key. + + + + + + Verify that the PDU is syntactically correct, and extract + the Auth Type, Key, Sig Type, and Signature fields. + + + + Verify that Auth Type and Sig Type refer to the same + algorithm suite, and that said algorithm suite is one that + the implementation understands. + + + + Construct the "message to be verified" by truncating the PDU + to remove the Signature field (in practice this should not + require copying any data, just subtract the signature length + from the PDU length). + + + + Verify the message constructed above against the public key + using the rules for the specific signature suite. + + + + Record Auth Type and Key as this sessions's authentication + type and session key, for use in verifying subseuqent PDUs. + + + + + + If any of the above verification steps fail, generate an error + using error code 2 ("Authorization failure in OPEN"). + + + + +
+ +
+ + + The process for verifying non-OPEN PDUs is slightly simpler, + but follows the same basic pattern as for OPEN PDUs. + + + + + + Verify that the PDU is syntactically correct, and extract + the Sig Type and Signature fields. + + + + Verify that Sig Type refers to the same algorithm suite as + the Auth Type recorded during verification of the OPEN PDU. + + + + Construct the "message to be verified" by truncating the PDU + to remove the Signature field. + + + + Verify the message constructed above against the recorded + session key using the rules for the specific signature + suite. + + + + + + If any of the above verification steps fail, generate an error + using error code 3 ("Signature failure in PDU"). + + + + +
+ +
+
-
+ + Using a PKI is almost the same as using TOFU, but with one + additional step: during verification of an OPEN PDU, after + extracting the Key field from the PDU but before attempting to + use it to verify the PDU's signature, the receiver MUST verify + the received key against the PKI to confirm that it's an + authorized key. + + + + Use of a PKI requires, at minimum, configuration of a trust + anchor and an End-Entity certificate corresponding to each peer + with which this l3dl instance is expected to establish sessions. + Optionally, a PKI MAY also allow configuration of zero or more + intermediate CA certificates and certificate revocation lists, + as needed to support an operator's preferred PKI architecture. + In general, however, we strongly recommend keeping the PKI as + simple as possible, because all of the configured PKI data must + be provided via out-of-band means, and will require maintenance. + + + + +
@@ -179,6 +355,14 @@ receiver eventually have a signature failure (error code 3) on a PDU. + + The rekeying operation changes the session key and algorithm + suite described in . The NEWKEY + PDU itself is verified using the old algorithm and session key, + subsequent PDUs are verified with the new algorithm and session + key recorded after the NEWKEY PDU has been accepted. + +