First pass on PDU signature and verification.

draft-ymbk-lsvr-l3dl-signing.xml

@@ -121,11 +121,187 @@
 
   <section anchor="tofu" title="Trust On First Use Method">
   
+    <t>There are three parts to using a key: signing PDUs, verifying
+    the OPEN PDU, and verifying subsequent PDUs.</t>
+
+    <section anchor="signing" title="Signing a PDU">
+
+      <t>All signed PDUs are generated in the same way:</t>
+
+      <list style="symbols">
+
+	<t>
+	  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.
+	</t>
+
+	<t>
+	  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.
+	</t>
+
+	<t>
+	  Construct the complete message by appending the signature
+	  octets to the otherwise complete message composed above.
+	</t>
+
+      </list>
+
+      <t>
+	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.
+      </t>
+
     </section>
 
+    <section anchor="verify-open" title="Verifying the OPEN PDU">
+
+      <t>
+	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.
+      </t>
+
+      <list style="symbols">
+
+	<t>
+	  Verify that the PDU is syntactically correct, and extract
+	  the Auth Type, Key, Sig Type, and Signature fields.
+	</t>
+
+	<t>
+	  Verify that Auth Type and Sig Type refer to the same
+	  algorithm suite, and that said algorithm suite is one that
+	  the implementation understands.
+	</t>
+
+	<t>
+	  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).
+	</t>
+
+	<t>
+	  Verify the message constructed above against the public key
+	  using the rules for the specific signature suite.
+	</t>
+
+	<t>
+	  Record Auth Type and Key as this sessions's authentication
+	  type and session key, for use in verifying subseuqent PDUs.
+	</t>
+
+      </list>
+
+      <t>
+	If any of the above verification steps fail, generate an error
+	using error code 2 ("Authorization failure in OPEN").
+      </t>
+
+      <!--
+	Why are we using a different error code for failures in OPEN
+	PDUs than we do in other PDUs?  We don't want to provide an
+	oracle, so we want to return the same error code for any
+	verification failure for a particular PDU, so the only effect
+	would be to have all failures in OPEN PDUs return a different
+	single error code than all failures in any other PDU would
+	use, which doens't seem useful.
+        -->
+
+    </section>
+
+    <section anchor="verify-other" title="Verifying Other PDUs">
+
+      <t>
+	The process for verifying non-OPEN PDUs is slightly simpler,
+	but follows the same basic pattern as for OPEN PDUs.
+      </t>
+
+      <list style="symbols">
+
+	<t>
+	  Verify that the PDU is syntactically correct, and extract
+	  the Sig Type and Signature fields.
+	</t>
+
+	<t>
+	  Verify that Sig Type refers to the same algorithm suite as
+	  the Auth Type recorded during verification of the OPEN PDU.
+	</t>
+
+	<t>
+	  Construct the "message to be verified" by truncating the PDU
+	  to remove the Signature field.
+	</t>
+
+	<t>
+	  Verify the message constructed above against the recorded
+	  session key using the rules for the specific signature
+	  suite.
+	</t>
+
+      </list>
+
+      <t>
+	If any of the above verification steps fail, generate an error
+	using error code 3 ("Signature failure in PDU").
+      </t>
+
+      <!--
+	See note in previous section regarding error codes.
+        -->
+
+    </section>
+
+  </section>
+
   <section anchor="pki" title="Public Key Infrastructure Method">
       
-    </section>
+    <t>
+      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.
+    </t>
+
+    <t>
+      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.
+    </t>
+
+    <!--
+      This would be easier if we were providing certificates rather
+      than raw public keys in the OPEN PDU, but that would create a
+      significant difference between the TOFU and PKI cases.  Not
+      happy about having to preconfigure all the peer EE certs, though,
+      so we might want to consider this.
+
+      Have deliberately not yet said "X.509v3" in so many words
+      because suspect LSVR people would run screaming from the room,
+      but that's another thing like TLS that it's probably just
+      not worth reinventing.
+      -->
+
+  </section>
 
   <section anchor="roll" title="NEWKEY, Key Roll">
 
@@ -179,6 +355,14 @@
     receiver eventually have a signature failure (error code 3) on a
     PDU.</t>
 
+    <t>
+      The rekeying operation changes the session key and algorithm
+      suite described in <xref target="verify-other"/>.  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.
+    </t>
+
     </section>
 
   <section anchor="security" title="Security Considerations">