Voucher Profile for Bootstrapping ProtocolsJuniper Networkskwatsen@juniper.netSandelman Softwaremcr+ietf@sandelman.cahttp://www.sandelman.ca/Cisco Systemspritikin@cisco.comFuturewei Technologies Inc.2330 Central ExpySanta Clara95050USAtte+ietf@cs.fau.de
Operations
ANIMA Working GroupvoucherThis document defines a strategy to securely assign a pledge to an owner,
using an artifact signed, directly or indirectly, by the pledge's manufacturer.
This artifact is known as a "voucher".The voucher artifact is a YANG-defined JSON document that has been
signed using a PKCS#7 structure. The voucher artifact is generated by
the pledge's manufacture or delegate (i.e. the MASA).This document only defines the voucher artifact, leaving it to other
documents to describe specialized protocols for accessing it.This document defines a strategy to securely assign a pledge to an owner,
using an artifact signed, directly or indirectly, by the pledge's manufacturer
or delegate (i.e. the MASA). This artifact is known as the voucher.The voucher artifact is a JSON document, conforming to a data model
described by YANG , that has been signed using
a PKCS#7 structure.A voucher may be useful in several contexts, but the driving motivation
herein is to support secure bootstrapping mechanisms. Assigning
ownership is important to bootstrapping mechanisms so that the pledge
can authenticate the network that's trying to take control of it.The lifetimes of vouchers may vary. In some bootstrapping protocols
the vouchers may be ephemeral, whereas in others the vouchers may be
potentially long-lived. In order to support the second category of vouchers,
this document recommends using short-life vouchers with programatic
renewal, enabling the MASA to communicate the ongoing validity of vouchers.This document only defines the voucher artifact, leaving it to other
documents to describe specialized protocols for accessing it. Some bootstrapping
protocols using the voucher artifact defined in this draft include:
,
, and
).The process where a device obtains the
cryptographic key material to identify and trust future
interactions with a network. This term is taken from Konrad
Lorenz's work in biology with new ducklings: "during a critical
period, the duckling would assume that anything that looks like a
mother duck is in fact their mother." An equivalent for a device is
to obtain the fingerprint of the network's root certification
authority certificate. A device that imprints on an attacker
suffers a similar fate to a duckling that imprints on a hungry
wolf. Securely imprinting is a primary focus of this
document.. The analogy to
Lorenz's work was first noted in .The set of entities or infrastructure under
common administrative control. The goal of the bootstrapping
protocol is to enable a Pledge to discover and join a Domain.A representative of the domain that is
configured, perhaps autonomically, to decide whether a new device
is allowed to join the domain. The administrator of the domain
interfaces with a Join Registrar (and Coordinator) to control this process. i
Typically a Join Registrar is "inside" its domain. For simplicity this document
often refers to this as just "Registrar".The Manufacturer Authorized Signing Authority (MASA)
service that signs vouchers. In some bootstrapping protocols, the
MASA may have Internet presence and be integral to the bootstrapping
process, whereas in other protocols the MASA may be an offline service
that has no active role in the bootstrapping process.The prospective device attempting to find and
securely join a domain. When shipped it only trusts authorized
representatives of the manufacturer.See Join RegistrarTrust on First Use. This is where a Pledge
device makes no security decisions but rather simply trusts the
first Domain entity it is contacted by. Used similarly to . This is also known as the "resurrecting
duckling" model.A signed statement from the MASA service
that indicates to a Pledge the cryptographic identity of the
Domain it should trust.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in the sections below are to be interpreted
as described in RFC 2119 .A voucher is a cryptographically protected statement to the Pledge
device authorizing a zero-touch "imprint" on the Join Registrar of the
domain. The specific information a voucher provides is influenced by the
bootstrapping use case.The voucher can impart the following information to
the Join Registrar and Pledge:Indicates the method that protects
the imprint (this is distinct from the voucher signature that
protects the voucher itself). This might include manufacturer
asserted ownership verification, assured logging operations or
reliance on Pledge endpoint behavior such as secure root of trust
of measurement. The Join Registrar might use this information.
Only some methods are normatively defined in this
document. Other methods are left for future work.Indicates how the Pledge
can authenticate the Join Registrar. This might include an indication
of the private PKIX trust anchor used by the Registrar, or an indication
of a public PKIX trust anchor and additional CN-ID or DNS-ID
information to complete authentication. Symmetric key or other
methods are left for future work.Time or nonce based
information to constrain the voucher to time periods or bootstrap
attempts.A number of bootstrapping scenarios can be met using differing
combinations of this information. All scenarios address the primary
threat of a Man-in-The-Middle Registrar gaining control over the Pledge device. The
following combinations are "types" of vouchers:An Audit Voucher is named after the
logging assertion mechanisms that the Registrar then "audits" to
enforce local policy. The Registrar mitigates a MiTM Registrar by
auditing that an unknown MiTM registrar does not appear in the log
entries. This does not direct prevent the MiTM but provides a
response mechanism that ensures the MiTM is unsuccessful. This
advantage is that actual ownership knowledge is not required on
the MASA service.An Audit Voucher without a
validity period statement. Fundamentally the same as an Audit
Voucher except that it can be issued in advance to support network
partitions or to provide a permanent voucher for remote
deployments.An Audit Voucher where the
MASA service has verified the Registrar as the authorized owner.
The MASA service mitigates a MiTM Registrar by refusing to
generate Audit Voucher's for unauthorized Registrars. The
Registrar uses audit techniques to supplement the MASA. This
provides an ideal sharing of policy decisions and enforcement
between the vendor and the owner.An Ownership ID Voucher is
named after inclusion of the Pledge's CN-ID or DNS-ID within the
voucher. The MASA service
mitigates a MiTM Registrar by identifying the specific Registrar
(via WebPKI) authorized to own the Pledge. A Bearer Voucher is named after the
inclusion of a Registrar ID wildcard. Because the Registrar identity
is not indicated this voucher type must be treated as a
secret and protected from exposure as any 'bearer' of the voucher
can claim the Pledge device. Publishing a nonceless
bearer voucher effectively turns the specified Pledge into a
"TOFU" device with minimal mitigation against MiTM Registrars. Bearer
vouchers are out-of-scope.The voucher's purpose is to securely assign a pledge to an owner.
The voucher informs the pledge which entity it should consider to be
its owner.The voucher is signed a PKCS#7 SignedData structure, as specified
by Section 9.1 of , encoded using ASN.1
distinguished encoding rules (DER), as specified in ITU-T X.690.The PKCS#7 structure MUST contain JSON-encoded content conforming
to the YANG module specified in .The PKCS#7 structure MUST also contain a 'signerInfo' structure, as
described in Section 9.1 of , containing the
signature generated over the content using the MASA's private key.The PKCS#7 structure SHOULD also contain all of the certificates
leading up to and including the MASA's trust anchor certificate
known to the pledges.The PKCS#7 structure MAY also contain revocation objects for any
intermediate CAs between the voucher-issuer and the trust anchor
known to the pledge.The following tree diagram
illustrates a high-level view of a voucher document. Each field
in the voucher is fully described by the YANG module provided in
. Please review this YANG
module for a detailed description of the voucher format.This section provides a couple Voucher examples for illustration
purposes.The following example illustrates an ephemeral voucher (uses a nonce)
encoded in JSON. As is expected with a dynamically-generated voucher,
only a single pledge (device-identifier) is specified. The MASA
generated this voucher using the 'logged' assertion type, knowing
that it would be suitable for the pledge making the request.The following illustrates a long-lived voucher (no nonce), encoded in XML.
This particular voucher applies to more than one pledge (unique-id), which
might relate to, for instance, they were all issued as part of the same
purchase order. This voucher includes both a trust anchor
certificate (trusted-ca-certificate) as well as some additional information
(cn-id and dns-id) that can be used to identify a specific domain certificate
issued, perhaps indirectly, by the trust anchor CA.The lifetimes of vouchers may vary. In some bootstrapping protocols, the
vouchers may be created and consumed immediately whereas, in other bootstrapping
solutions, there may be a significant delay between when a voucher is created
and when it is consumed. In cases when there is a delay, there is a need for
the pledge to ensure that the assertions made when the voucher was created are
still valid when it is consumed.A revocation artifact is generally used to verify the continued validity
of an assertion such as a PKIX certificate, web token, or a "voucher". With
this approach, a potentially long-lived assertion is paired with a reasonably
fresh revocation status check to ensure that the assertion is still valid.
However, this approach increases solution complexity, as it introduces the
need for additional protocols and code paths to distribute and process the
revocations.Addressing the short-comings of revocations, this document recommends
instead the use of lightweight renewals of short-lived non-revocable
vouchers. That is, rather than issue a long-lived voucher, the expectation
is for the MASA to instead issue a short-lived voucher along with a promise
(reflected in the 'last-renewal-date' field) to re-issue the voucher again
when needed. Importantly, while issuing the initial voucher may incur
heavyweight verification checks (are you who you say you are? does the
pledge actually belong to you?), re-issuing the voucher should be a
lightweight process, as it ostensibly only updates the voucher's
validatity period. With this approach, there is only the one artifact,
and only one code path is needed to process it, without any possibility
for a pledge to choose to skip the revocation status check because, for
instance, the OCSP Responder is not reachable.While this document recommends issuing short-lived vouchers, the
voucher artifact does not restrict the ability to create a long-lived
vouchers, if required, however no revocation method is described.Note that a voucher may be signed by a chain of intermediate CAs
leading up to the trust anchor certificate known by the pledge. Even
though the voucher itself is not revocable, it may still be revoked,
per se, if one of the intermediate CA certificates is revoked.The solution described herein originally enabled a single voucher to
apply to many pledges, using lists of regular expressions to represent
ranges of serial numbers. However, it was determined that blocking the
renewal of a voucher that applied to many devices would be excessive
when only the ownership for a single pledge needed to be blocked.
Thus, the voucher format now only supports a single serial-number
to be listed.
An attacker could use an expired voucher to gain control over
a device that has no understand of time.
To defend against this there are three things: devices are
required to verify that the expires-on field has not yet passed.
Devices without access to time can use nonces to
get ephermal vouchers.
Thirdly, vouchers without expiration times may be used, which
will appear in the audit log, informing the security decision.
This document defines artifacts containing time values
for voucher expirations, which require an accurate clock
in order to be processed correctly. Vendors planning on
issuing vouchers with expiration values must ensure devices
have an accurate clock when shipped from manufacturing
facilities, and take steps to prevent clock tampering.
If it is not possible to ensure clock accuracy then
vouchers with expirations should not be issued.A voucher is signed by a CA, that may itself be signed by a chain of
CAs leading to a trust anchor known to a pledge. Revocation checking
of the intermediate certificates may be difficult in some scenarios.
The voucher format supports the existing PKIX revocation information
distribution within the limits of the current PKI technology (a PKCS7
structure can contain revocation objects as well), but pledges MAY
accept vouchers without checking X.509 certificate revocation (when
'domain-cert-revocation-checks' is false). Without revocation checking,
a compromized MASA keychain could be used to issue vouchers ad infinitum
without recourse. For this reason, MASA implementations wanting to
support such deployments SHOULD ensure that all the CA private keys
used for signing the vouchers are protected by hardware security
modules (HSMs).If a domain certificate is compromised, then any outstanding
vouchers for that domain could be used by the attacker. The domain
administrator is clearly expected to initiate revocation of any
domain identity certificates (as is normal in PKI solutions).
Similarly they are expected to contact the MASA to indicate that
an outstanding (presumably short lifetime) voucher should be blocked from
automated renewal. Protocols for voucher distribution are RECOMMENDED
to check for revocation of any domain identity certificates before
automated renewal of vouchers.This document registers a URIs in the IETF XML
registry . Following the format in
, the following registration is
requested:This document registers a YANG module in the
YANG Module Names registry .
Following the format defined in , the
the following registration is requested:YANG Tree DiagramsTail-f SystemsLABNThe resurrecting duckling: security issues for ad-hoc
wireless networksWikipedia article: ImprintingThe authors would like to thank for following for
lively discussions on list and in the halls (ordered
by last name):