Detail PKI now that we know how it works.
This commit is contained in:
parent
b0aa9c35b2
commit
141d1ba4ea
1 changed files with 133 additions and 57 deletions
|
|
@ -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
|
||||
document describes two mechanisms based on digital signatures, one
|
||||
that is Trust On First Use (TOFU), and one that uses certificates to
|
||||
provide authentication as well as session integrity.</t>
|
||||
key and a certificate, which can be used to verify signatures on
|
||||
subsequent PDUs. This document describes two mechanisms based on
|
||||
digital signatures, one that is Trust On First Use (TOFU), and one
|
||||
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
|
||||
draft not yet pushed] <xref target="I-D.ietf-lsvr-lsoe"/> OPEN PDU
|
||||
contains an algorithm specifier 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 Layer 3 Discovery and Liveness protocol [old ref because
|
||||
new draft not yet pushed] <xref target="I-D.ietf-lsvr-lsoe"/> OPEN
|
||||
PDU contains an algorithm specifier, a key, and a 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 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
|
||||
certificate, which is signed by the the operational environment's
|
||||
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>
|
||||
public key is put into a certificate, which is signed by the the
|
||||
operational environment's 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>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
|
||||
signed" for purposes of the signature algorithm.
|
||||
"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.
|
||||
</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
|
||||
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.
|
||||
Generating an OPEN PDU using the PKI method requires a
|
||||
certificate, which must be supplied via out of band
|
||||
configuration. The certificate is a signature of the public key
|
||||
to be sent in the Key field of the OPEN PDU, signed by the trust
|
||||
anchor private key.
|
||||
</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.
|
||||
<t>
|
||||
Verifying an OPEN PDU using the PKI method requires the public
|
||||
key of the trust anchor, which the receiver uses to verify the
|
||||
certificate, thereby demonstrating that the supplied is
|
||||
represents an authorized L3DL speaker in this administrative
|
||||
domain.
|
||||
</t>
|
||||
|
||||
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.
|
||||
-->
|
||||
<t>
|
||||
We use the term "certificate" here in the generic sense. These
|
||||
are not X.509 certificates: X.509 is much more complicated than
|
||||
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 ... | Old Sig Type |
|
||||
| New Key Length | New Key ... |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| | 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
|
||||
replacement algorithm suite and key.</t>
|
||||
<t>The New Key Type, New Key Length, New Key, New Cert Length, and
|
||||
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
|
||||
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.
|
||||
suite described in <xref target="tofu-other-verifying"/>. 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>
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue