Detail PKI now that we know how it works.

draft-ymbk-lsvr-l3dl-signing.xml

@@ -59,10 +59,11 @@
   <abstract>
 
     <t>The Layer 3 Discovery and Liveness protocol OPEN PDU contains a
-    key which can be used to verify signatures on subsequent PDUs.  This
+    key and a certificate, which can be used to verify signatures on
-    document describes two mechanisms based on digital signatures, one
+    subsequent PDUs.  This document describes two mechanisms based on
-    that is Trust On First Use (TOFU), and one that uses certificates to
+    digital signatures, one that is Trust On First Use (TOFU), and one
-    provide authentication as well as session integrity.</t>
+    that uses certificates to provide authentication as well as
+    session integrity.</t>
 
   </abstract>
 
@@ -82,13 +83,13 @@
 
   <section anchor="intro" title="Introduction">
 
-    <t>The Layer 3 Discovery and Liveness protocol [old ref because new
+    <t>The Layer 3 Discovery and Liveness protocol [old ref because
-    draft not yet pushed] <xref target="I-D.ietf-lsvr-lsoe"/> OPEN PDU
+    new draft not yet pushed] <xref target="I-D.ietf-lsvr-lsoe"/> OPEN
-    contains an algorithm specifier and a key which can be used to
+    PDU contains an algorithm specifier, a key, and a certificate,
-    verify signatures on subsequent PDUs.  This document describes two
+    which can be used to verify signatures on subsequent PDUs.  This
-    methods of key generation and signing for use by L3DL, Trust On
+    document describes two methods of key generation and signing for
-    First Use (TOFU) and a PKI-based mechanism to provide authentication
+    use by L3DL, Trust On First Use (TOFU) and a PKI-based mechanism
-    as well as session integrity.</t>
+    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
@@ -101,11 +102,10 @@
     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
+    public key is put into a certificate, which is signed by the the
-    certificate, which is signed by the the operational environment's
+    operational environment's trust anchor.  In this way, the relying
-    trust anchor.  In this way, the relying party can be confident that
+    party can be confident that the public key is under control of the
-    the public key is under control of the identified L3DL protocol
+    identified L3DL protocol entity.</t>
-    entity.</t>
 
     <t>To the receiver verifying signatures on PDUs, the two methods are
     indistinguishable; the key provided in the OPEN PDU is used to
@@ -115,7 +115,7 @@
 
     <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
-    subsequent PDUs from the same peer with the same Key Type.</t>
+    subsequent PDUs in the session.</t>
 
     </section>
 
@@ -124,7 +124,7 @@
     <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">
+    <section anchor="tofu-pdu-signing" title="Signing a PDU">
 
       <t>All signed PDUs are generated in the same way:</t>
 
@@ -134,8 +134,10 @@
 	  <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
+	    "Signature" field itself.  The Certificate Length should
-	    signed" for purposes of the signature algorithm.
+	    be zero and the Certificate field should be empty.  This
+	    is the "message to be signed" for purposes of the
+	    signature algorithm.
 	  </t>
 
 	  <t>
@@ -165,7 +167,7 @@
 
     </section>
 
-    <section anchor="verify-open" title="Verifying the OPEN PDU">
+    <section anchor="tofu-open-verifying" title="Verifying the OPEN PDU">
 
       <t>
 	The process for verifying an OPEN PDU is slightly different
@@ -224,7 +226,7 @@
 
     </section>
 
-    <section anchor="verify-other" title="Verifying Other PDUs">
+    <section anchor="tofu-other-verifying" title="Verifying Other PDUs">
 
       <t>
 	The process for verifying non-OPEN PDUs is slightly simpler,
@@ -283,29 +285,100 @@
     </t>
 
     <t>
-      Use of a PKI requires, at minimum, configuration of a trust
+      Generating an OPEN PDU using the PKI method requires a
-      anchor and an End-Entity certificate corresponding to each peer
+      certificate, which must be supplied via out of band
-      with which this l3dl instance is expected to establish sessions.
+      configuration.  The certificate is a signature of the public key
-      Optionally, a PKI MAY also allow configuration of zero or more
+      to be sent in the Key field of the OPEN PDU, signed by the trust
-      intermediate CA certificates and certificate revocation lists,
+      anchor private key.
-      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>
 
-    <!--
+    <t>
-      This would be easier if we were providing certificates rather
+      Verifying an OPEN PDU using the PKI method requires the public
-      than raw public keys in the OPEN PDU, but that would create a
+      key of the trust anchor, which the receiver uses to verify the
-      significant difference between the TOFU and PKI cases.  Not
+      certificate, thereby demonstrating that the supplied is
-      happy about having to preconfigure all the peer EE certs, though,
+      represents an authorized L3DL speaker in this administrative
-      so we might want to consider this.
+      domain.
+    </t>
 
-      Have deliberately not yet said "X.509v3" in so many words
+    <t>
-      because suspect LSVR people would run screaming from the room,
+      We use the term "certificate" here in the generic sense.  These
-      but that's another thing like TLS that it's probably just
+      are not X.509 certificates: X.509 is much more complicated than
-      not worth reinventing.
+      we need for I3DL.  The certificates used here are just
-      -->
+      signatures of one key (the session key supplied in the Key field
+      of the OPEN PDU) by another key (the trust anchor).
+    </t>
+
+    <section anchor="pki-open-signing" title="Signing OPEN PDU with PKI">
+
+      <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.
+      </t>
+
+      <t>
+	Note that the Auth Type field applies to both the Key and
+	Certificate fields.  That is: the certificate uses the same
+	certificate suite as the session keys, L3DL does not support
+	cross-algorithm-suite certification.
+      </t> 
+
+    </section>
+
+    <section anchor="verify-pki-open" title="Verifying OPEN PDU with PKI">
+
+      <t>
+	Verifying the OPEN PDU with PKI is similar to verifying with
+	TOFU as described in <xref target="tofu-open-verifying"/>, but
+	includes one critical extra step:
+      </t>
+
+      <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"/>.
+      </t>
+
+    </section>
+
+  </section>
+
+  <section anchor="local-policy" title="Local Policy">
+
+    <t>
+      Whether to use TOFU, PKI, or no signatures at all is a matter of
+      local policy, to be decided by the operator.  The useful
+      policy combinations for Key and Certificate are probably:
+    </t>
+
+    <t>
+      <list style="symbols">
+
+	<t>
+	  Not signing: sender need not sign, receiver does not check.
+	</t>
+
+	<t>
+	  Require TOFU: sender MUST supply key and receiver MUST
+	  check, certificate not needed and ignored if sent.
+	</t>
+
+	<t>
+	  Allow TOFU: sender must supply key and receiver MUST check,
+	  receiver SHOULD check certificate if supplyed by sender.
+	</t>
+
+	<t>
+	  Require PKI: sender must supply key and certificate,
+	  receiver must check both.
+	</t>
+
+      </list>
+    </t>
 
   </section>
 
@@ -319,7 +392,7 @@
     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 ...:32,New Cert Length:16,New Certificate ...:32,Old Sig Type:8,Old Signature Length:16,Old Signature ...:40"
 -->
 
       <figure>
@@ -329,19 +402,22 @@
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Type = 8   |         Payload Length        |  New Key Type |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|         New Key Length        |                               ~
+|         New Key Length        |          New Key ...          |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-~                  New Key ...                  |  Old Sig Type |
+|                               |        New Cert Length        |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                      New Certificate ...                      |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|  Old Sig Type |      Old Signature Length     |               |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
+|                       Old Signature ...                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|      Old Signature Length     |                               ~
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+
-~               Old Signature ...               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          </artwork>
       </figure>
 
-    <t>The New Key Type, New Key Length, and New Key fields declare the
+    <t>The New Key Type, New Key Length, New Key, New Cert Length, and
-    replacement algorithm suite and key.</t>
+    New Certificate field declare the replacement algorithm suite,
+    key, and certificate.</t>
 
     <t>The NEWKEY PDU is signed using the current (soon to be old)
     algorithm suite and key.</t>
@@ -363,10 +439,10 @@
 
     <t>
       The rekeying operation changes the session key and algorithm
-      suite described in <xref target="verify-other"/>.  The NEWKEY
+      suite described in <xref target="tofu-other-verifying"/>.  The
-      PDU itself is verified using the old algorithm and session key,
+      NEWKEY PDU itself is verified using the old algorithm and
-      subsequent PDUs are verified with the new algorithm and session
+      session key, subsequent PDUs are verified with the new algorithm
-      key recorded after the NEWKEY PDU has been accepted.
+      and session key recorded after the NEWKEY PDU has been accepted.
     </t>
 
     </section>
@@ -387,7 +463,7 @@
     the same as in the TOFU method.</t>
 
     <t>With the PKI-based method, automated device provisioning could
-    restrict which subsidiary certificates are allowed from which peers
+    restrict which certificates are allowed from which peers
     on a per interface basis.  This would complicate key rolls.  Where
     one draws the line between rigidity, flexibility, and security
     varies.</t>