551 lines
19 KiB
XML
551 lines
19 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
|
|
<?rfc comments="yes"?>
|
|
<?rfc compact="yes"?>
|
|
<?rfc subcompact="no"?>
|
|
<?rfc inline="yes"?>
|
|
<?rfc sortrefs="yes"?>
|
|
<?rfc symrefs="yes"?>
|
|
<?rfc toc="yes"?>
|
|
<?rfc tocdepth="6"?>
|
|
<?rfc tocindent="yes"?>
|
|
<?rfc tocompact="yes"?>
|
|
|
|
<rfc consensus="yes" category="std" docName="draft-ietf-lsvr-l3dl-signing-03" ipr="trust200902">
|
|
|
|
<front>
|
|
|
|
<title>Layer-3 Discovery and Liveness Signing</title>
|
|
|
|
<author fullname="Randy Bush" initials="R." surname="Bush">
|
|
<organization>Arrcus & IIJ</organization>
|
|
<address>
|
|
<postal>
|
|
<street>5147 Crystal Springs</street>
|
|
<city>Bainbridge Island</city>
|
|
<region>WA</region>
|
|
<code>98110</code>
|
|
<country>United States of America</country>
|
|
</postal>
|
|
<email>randy@psg.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author fullname="Russ Housley" initials="R" surname="Housley">
|
|
<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
|
|
<address>
|
|
<postal>
|
|
<street>516 Dranesville Road</street>
|
|
<city>Herndon</city>
|
|
<region>VA</region>
|
|
<code>20170</code>
|
|
<country>USA</country>
|
|
</postal>
|
|
<email>housley@vigilsec.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author initials="R." surname="Austein" fullname="Rob Austein">
|
|
<organization abbrev="Arrcus">Arrcus, Inc.</organization>
|
|
<address>
|
|
<email>sra@hactrn.net</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date />
|
|
|
|
<abstract>
|
|
|
|
<t>The Layer-3 Discovery and Liveness protocol OPEN PDU may contain
|
|
a public 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 a trust anchor signture over the public key to provide
|
|
authentication as well as session integrity.</t>
|
|
|
|
</abstract>
|
|
|
|
<note title="Requirements Language">
|
|
|
|
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
|
"OPTIONAL" in this document are to be interpreted as described in
|
|
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
|
|
and only when, they appear in all capitals, as shown here.</t>
|
|
|
|
</note>
|
|
|
|
</front>
|
|
|
|
<middle>
|
|
|
|
<section anchor="intro" title="Introduction">
|
|
|
|
<t>The Layer-3 Discovery and Liveness protocol <xref
|
|
target="I-D.ietf-lsvr-l3dl"/> OPEN PDU contains an algorithm
|
|
identifier, a key, and a L3DL 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
|
|
device sending the OPEN PDU may use one key for all links, a different
|
|
key for each link, or some mix(es) thereof.</t>
|
|
|
|
<t>In the TOFU method the key sent in the OPEN PDU is generated on
|
|
the sending device, is believed without question by the receiver,
|
|
and used to verify all subsequent PDUs from the same sender with the
|
|
same public key and algorithm.</t>
|
|
|
|
<t>With the PKI method, an enrollment step is performed. The public
|
|
key 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>As part of enrollment or before hand, all relying parties must
|
|
have received the trust anchor in an authentic manner.</t>
|
|
|
|
<t>To the receiver verifying signatures on PDUs, the two methods are
|
|
indistinguishable; the key provided in the OPEN PDU is used to
|
|
verify the signatures of subsequent PDUs. The difference that
|
|
PKI-based keys may be verified against the trust anchor when the
|
|
OPEN PDU is received.</t>
|
|
|
|
<t>In the PKI method the public key in the OPEN PDU MUST be verified
|
|
against the trust anchor for the operational domain. The OPEN PDU
|
|
public key is then used to verify all subsequent PDUs in the
|
|
session. A mechanism for 'rolling' from the current public key
|
|
to a fresh one is described in <xref target="roll"/>.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="algo" title="Signature Algorithm Identifiers">
|
|
|
|
<t>To avoid the creation of yet another IANA registry for
|
|
digital signature algorithm identifiers, this specification makes
|
|
use of the existing IANA registry for "DNS Security Algorithm Numbers"
|
|
<xref target="IANA"/>. In this registry, each signature algorithm is
|
|
identified by an 8-bit value. The entries in this registry with "Y"
|
|
in the "Zone Signing" column are appropriate for use with this
|
|
protocol.</t>
|
|
|
|
<t>For interoperability, all implementations of this protocol MUST
|
|
support the RSASHA256 algorithm (identified by the value 0x08).
|
|
Implementation MAY support any other registered "Zone Signing"
|
|
signature algorithms.</t>
|
|
|
|
</section>
|
|
|
|
|
|
<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="tofu-pdu-signing" title="Signing a PDU">
|
|
|
|
<t>All signed PDUs are generated in the same way:</t>
|
|
|
|
<t>
|
|
<list style="symbols">
|
|
|
|
<t>
|
|
Compose the PDU, with all fields including "Sig Algo" and
|
|
"Signature Length" set, but omitting the trailing
|
|
"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>
|
|
Generate the signature as specified for the chosen algorithm,
|
|
using the private key 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 signature algorithm. The result will be a sequence of
|
|
octets, the length of which MUST be equal to the value in 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>
|
|
|
|
<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="tofu-open-verifying" 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>
|
|
|
|
<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>
|
|
|
|
<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="tofu-other-verifying" 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>
|
|
|
|
<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>
|
|
|
|
<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">
|
|
|
|
<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 OPEN PDU signature, the receiver MUST verify the
|
|
received key against the PKI to confirm that it's an authorized
|
|
key.
|
|
</t>
|
|
|
|
<t>
|
|
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>
|
|
|
|
<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 public key
|
|
represents an authorized L3DL speaker in this administrative
|
|
domain.
|
|
</t>
|
|
|
|
<t>
|
|
We use the term "certificate" here in the generic sense, not as
|
|
defined in <xref target="RFC5280"/>. X.509 certificates are not
|
|
used here; X.509 certificates are more complicated than needed
|
|
for L3DL. The L3DL certificates are just signatures of one key
|
|
(the public key supplied in the Key field of the OPEN PDU) that
|
|
can be verified by another trusted public 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, but L3DL certificates 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 L3DL certificate,
|
|
receiver MUST check signature and verify the L3DL certificate.
|
|
</t>
|
|
|
|
</list>
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="roll" title="NEWKEY, Key Roll">
|
|
|
|
<t>Modern key management allows for agility in 'rolling' to a new
|
|
key or even algorithm in case of key expiry, key compromise, or
|
|
merely prudence. Declaring a new key with an L3DL OPEN PDU would
|
|
cause serious churn in topology as a new OPEN PDU may cause a
|
|
withdraw of previously announced encapsulations. Therefore, a
|
|
gentler rekeying is needed.</t>
|
|
|
|
<t>Prior to 'rolling' to a new key or new algorithm, a new public/private
|
|
key pair is generated. If PKI is being used, then the trust anchor
|
|
also signs the new public key to create a new L3DL certificate.</t>
|
|
|
|
<!--
|
|
protocol "Type = 8:8,Payload Length:16,New Key Algor: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>
|
|
<artwork>
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Type = 8 | Payload Length | New Key Type |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| New Key Length | New Key ... |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| | New Cert Length |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| New Certificate ... |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Old Key Type | Old Signature Length | |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|
|
| Old Signature ... |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
</artwork>
|
|
</figure>
|
|
|
|
<t>The New Key Type, New Key Length, New Key, New Cert Length, and
|
|
New Certificate fields declare the replacement algorithm, key, and
|
|
L3DL certificate.</t>
|
|
|
|
<t>The NEWKEY PDU is signed using the current (soon to be old)
|
|
algorithm and key.</t>
|
|
|
|
<t>The sender and the receiver should be cautious of signature
|
|
algorithm downgrade attacks.</t>
|
|
|
|
<t>To avoid possible race conditions, the receiver SHOULD accept
|
|
signatures using either the new or old key for a configurable time
|
|
(default 30 seconds). This is intended to accommodate situations
|
|
such as senders with high peer out-degree and a single per-device
|
|
asymmetric key.</t>
|
|
|
|
<t>If the sender does not receive an ACK in the normal window,
|
|
including retransmission, then the sender MAY choose to allow a
|
|
session reset by either issuing a new OPEN PDU or by letting the
|
|
receiver eventually have a signature failure (error code 3) on a
|
|
PDU.</t>
|
|
|
|
<t>
|
|
The rekeying operation changes the session key and the associated
|
|
algorithm described in <xref target="tofu-other-verifying"/>. The
|
|
NEWKEY PDU itself is verified using the old algorithm and session
|
|
key. After the NEWKEY PDU has been accepted, subsequent PDUs are
|
|
verified with the new algorithm and the new session key.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="security" title="Security Considerations">
|
|
|
|
<t>The TOFU method requires a leap of faith to accept the key in the
|
|
OPEN PDU, as it can not be verified against any authority. Hence it
|
|
is jokingly referred to as Married On First Date. The assurance it
|
|
does provide is that subsequent signed PDUs are from the same peer.
|
|
And data integrity is a positive side effect of the signature
|
|
covering the payload.</t>
|
|
|
|
<t>The PKI method offers assurance that the L3DL certificate, and
|
|
hence the public key, provided in the OPEN PDU are authorized
|
|
by a central authority, e.g. the network's security team. The
|
|
onward assurance of talking to the same peer and data integrity are
|
|
the same as in the TOFU method.</t>
|
|
|
|
<t>With the PKI method, automated device provisioning could
|
|
restrict which L3DL 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>
|
|
|
|
<t>The REKEY PDU is open to abuse to create a signature algorithm
|
|
downgrade attack.</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="iana" title="IANA Considerations">
|
|
|
|
<t>This document requests the IANA create a new entry in the L3DL PDU
|
|
Type registry as follows:</t>
|
|
<figure>
|
|
<artwork>
|
|
PDU
|
|
Code PDU Name
|
|
---- -------------------
|
|
8 NEWKEY
|
|
</artwork>
|
|
</figure>
|
|
|
|
<t>This document requests the IANA add registry entries for "TOFU -
|
|
Trust On First Use" and "PKI" to the L3DL-Signature-Type registry as
|
|
follows:</t>
|
|
<figure>
|
|
<artwork>
|
|
Number Name
|
|
------ -------------------
|
|
1 TOFU - Trust On First Use
|
|
2 PKI
|
|
</artwork>
|
|
</figure>
|
|
|
|
</section>
|
|
|
|
</middle>
|
|
|
|
<back>
|
|
|
|
<references title="Normative References">
|
|
<?rfc include="reference.RFC.2119.xml"?>
|
|
<?rfc include="reference.RFC.8174.xml"?>
|
|
<?rfc include="reference.I-D.ietf-lsvr-l3dl.xml"?>
|
|
<reference anchor="IANA" target="https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml">
|
|
<front>
|
|
<title>DNS Security Algorithm Numbers</title>
|
|
<author/>
|
|
<date/>
|
|
</front>
|
|
</reference>
|
|
</references>
|
|
|
|
<references title="Informative References">
|
|
<?rfc include="reference.RFC.5280.xml"?>
|
|
</references>
|
|
|
|
</back>
|
|
|
|
</rfc>
|