One document matched: draft-pritikin-bootstrapping-keyinfrastructures-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited by Steinthor Bjarnason -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-homenet-arch PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-homenet-arch.xml">
<!ENTITY I-D.behringer-autonomic-network-framework PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.behringer-autonomic-network-framework.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7030 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7030.xml">
]>
<rfc category="info"
docName="draft-pritikin-bootstrapping-keyinfrastructures-01"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Bootstrapping Key Infrastructures</title>
<author fullname="Max Pritikin" initials="M." surname="Pritikin">
<organization>Cisco</organization>
<address>
<email>pritikin@cisco.com</email>
</address>
</author>
<author fullname="Michael H. Behringer" initials="M.H."
surname="Behringer">
<organization>Cisco</organization>
<address>
<email>mbehring@cisco.com</email>
</address>
</author>
<author fullname="Steinthor Bjarnason" initials="S." surname="Bjarnason">
<organization>Cisco</organization>
<address>
<email>sbjarnas@cisco.com</email>
</address>
</author>
<date day="26" month="September" year="2014"/>
<abstract>
<t>This document specifies automated bootstrapping of an key
infrastructure using vendor installed IEEE 802.1AR manufacturing
installed certificates, in combination with a vendor based cloud
service. Before being authenticated, a new device has only link-local
connectivity, and does not require a routable address. When a vendor
cloud service is provided devices can be forced to join only specific
domains but for contrained environments we describe a variety of options
that allow bootstrapping to proceed.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>To literally "pull yourself up by the bootstraps" is an impossible
action. Similarly the secure establishment of a key infrastructure
without external help is also an impossibility. Today it is accepted
that the initial connections between nodes are insecure, until key
distribution is complete, or that domain-specific keying material is
pre-provisioned on each new device in a costly and non-scalable manner.
This document describes a zero-touch approach to bootstrapping an entity
by securing the initial distribution of key material using third-party
generic keying material, such as a manufacturer installed IEEE 802.1AR
certificate <xref target="IDevID"/>, and a corresponding third-party
cloud service.</t>
<t>The two sides of an association being bootstrapped authenticate each
other and then determine appropriate authorization. This process is
described as four distinct steps between the existing domain and the new
entity being added:</t>
<t><list style="symbols">
<t>New entity authentication: "Who is this? What is its
identity?"</t>
<t>New entity authorization: "Is it mine? Do I want it? What are the
chances it has been compromised?"</t>
<t>Domain authentication: "What is this domain's claimed
identity?"</t>
<t>Domain authorization: "Should I join it?"</t>
</list></t>
<t>A precise answer to these questions can not be obtained without
leveraging an established key infrastructure(s). The domain's decisions
are based on the new entity's authenticated identity, as established by
verification of previously installed credentials such as a manufacturer
installed IEEE 802.1AR certificate, and verified back-end information
such as a configured list of purchased devices or communication with a
trusted third-party. The new entity's decisions are made according to
verified communication with a trusted third-party or in a strictly
auditable fasion.</t>
<t>Optimal security is achieved with IEEE 802.1AR certificates on each
new entity, accompanied by a third-party cloud service for verification.
The concept also works with less requirements, but is then less secure.
A domain can choose to accept lower levels of security when a trusted
third-party is not available so that bootstrapping proceeds even at the
risk of reduced security. Only the domain can make these decisions based
on administrative input and known behavior of the new entity.</t>
<t>The result of bootstrapping is that a domain specific key
infrastructure is deployed. Since IEEE 802.1AR PKI certificates are used
for identifying the new entity and the public key of the domain identity
is leveraged during communiciations with a cloud service, which is
itself authenticated using HTTPS, bootstrapping of a domain specific
Public Key Infrastructure (PKI) is fully described. Sufficient agility
to support bootstrapping alternative key infrastructures (such as
symmetric key solutions) is considered although no such key
infrastructure is described.</t>
<section title="Terminology">
<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
<xref target="RFC2119"/>.</t>
<t>The following terms are defined for clarity:</t>
<t/>
</section>
</section>
<section title="Architectural Overview">
<t>The logical elements of the bootstrapping framework are described in
this section. Figure 1 provides a simplified overview of the components.
Each component is logical and may be combined with other components as
necessary.</t>
<t><figure>
<artwork><![CDATA[ Factory components
.
. +------------+
. | Factory CA |
. +------------+
. |
. +------------+
. | |
+--------------(provides)---------------------------| Factory |
| +---------->| |
| | . +------------+
| V .
| +---------------+ . +------------+
| | Orchestrator | . | MASA |
V +---------------+ . | Cloud |
+-------+ | . | Service |
| New | +------------+ +-----------+ . +------------+
| Entity|<--L2-->| Proxy |<----->| | ....... ^
| | +------------+ | | |
| | | Registrar | |
| | | | |
| |<--DHCP-->(L3 bootstrap) | | |
| | | | |
| |<-----L3---------------------( registrar )-----------+
| | ( may proxy ) |
+-------+ +-----------+
|
+----------------------------+
^ | Domain Certification | ^
. | Authority | .
. +----------------------------+ .
. .
.........................................
|
"domain" components
]]></artwork>
</figure>Figure 1</t>
<t><list style="hanging">
<t hangText="Domain:">The set of entities that trust a common key
infrastructure trust anchor.</t>
<t hangText="Domain CA:">The domain Certification Authority (CA)
optionally provides certification functionalities to the domain
entities. At a minimum it provides certification funtionalities to
the Registrar and stores the trust anchor that defines the
domain.</t>
<t hangText="Domain Identity:">The domain identity is the 160-bit
SHA-1 hash of the BIT STRING of the subjectPublicKey of the domain
trust anchor that is stored by the Domain CA. This is consistent
with the RFC5280 Certification Authority subject key identifier of
the Domain CA's self signed root certificate. (A string value bound
to the Domain CA's self signed root certificate subject and issuer
fields is often colloqually used as a humanized identity value but
during protocol discussions the more exact term as defined here is
used).</t>
<t hangText="Orchestrator:">Although bootstrapping of an individual
device is automated and requires zero administrative involvement
(particularly on the New Entity) the orchestrator drives general
operations of the domain. In simple deployments this might be a
single administrator ordering a new device from the Factory and
manually inputing a serial number from the bill-of-sale into a
Registrar. In a more complex environment this might be an automated
process that directs a hypervisor "Factory" to instantiate a new
virtual machine.</t>
<t hangText="Factory:">This instantiates the New Entity. For
physical devices this can be representative of third-party vendor
manufacturing, ordering and shipping process(es) that results in a
physical hardware device with an IEEE 802.1AR identity being drop
shipped to a destination domain for physical installation. In a
virtual machine environment this can be the virtual machine
hypervisor control software that initiates a virtual machine
instance, in which case the factory is a "virtual factory" and might
be managed by the domain itself.</t>
<t hangText="Factory CA:">This Certification Authority is leveraged
by the Factory to issue IEEE 802.1AR identities to each New Entity.
For a virtual factory it may be reasonable to assume the domain
certification authority is directly used but in a complex
environment it is assumed the Factory does not have direct access to
the Domain Certification Authority.</t>
<t hangText="Registrar:">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 Registrar to control this process.</t>
<t hangText="New Entity:">A new device or virtual machine or
software component that is not yet part of the domain.</t>
<t hangText="Proxy:">A domain entity that helps the New Entity join
the domain. A Proxy facilitates communication for devices that find
themselves in an environment where they are not provided L3
connectivity until after they are validated as members of the
domain.</t>
<t hangText="MASA Cloud Service:">A Manufacturer Authorized Signing
Authority (MASA) cloud service on the global Internet. At a minimum
the MASA provides a trusted repository for audit information
concerning privacy protected bootstrapping events. As a service
offering the MASA can encorporate many of the bootstrapping elements
(such as the Registrar and the Domain CA) into the cloud
service.</t>
</list></t>
</section>
<section title="Operational Overview">
<t>This section describes how an operator interacts with a domain that
supports the bootstrapping as described in this document.</t>
<section title="Instantiating the Domain Certification Authority">
<t>This is a one time step by the domain administrator. This is an
"off the shelf" CA with the exception that it is designed to work as
an integrated part of the security solution. This precludes the use of
3rd party certification authority services that do not provide support
for delegation of certificate issuance decisions to a domain managed
Registration Authority.</t>
</section>
<section title="Instantiating the Registrar">
<t>This is a one time step by the domain administrator. One or more
devices in the domain are configured take on a Registrar function.</t>
<t>A device can be configured to act as a Registrar or a device can
auto-select itself to take on this function, using a detection
mechanism to resolve potential conflicts and setup communication with
the Domain Certification Authority. An automated Registrar selection
processes is not detailed here. [[EDNOTE: yet]]</t>
</section>
<section title="Accepting New Entities">
<t>For each New Entity the Registrar is informed a priori the unique
identifier (e.g. serial number). This can be supplied automatically
from the Orchestrator [[EDNOTE: TBD]] or inputed manually by the
administrator.</t>
<t>For each entity that will be accepted a Registrar maintains the
Factory CA identity and the entity's unique identifier. The Factory CA
identity could be implemented as the Factory CA root certificate
keyIdentifier (the 160-bit SHA-1 hash of the value of the BIT STRING
subjectPublicKey). For user interface purposes the keyIdentifier
information can be mapped to a colloquial Factory name (Registrars can
be shipped with the keyIdentifier of a significant number of
third-party manufacturers).</t>
<t>Additional policy can be stored for future authorization decisions.
For example an expected deployment time window or that a certain Proxy
must be used.</t>
</section>
<section title="Operating the Network">
<t>Once devices are enrolled to the domain, the network operator can
specify a policy, or otherwise configure the devices if required. This
is outside scope for this document.</t>
</section>
</section>
<section title="Functional Overview">
<t>Entities behave in an autonomic fashion. They discover each other and
autonomically establish a key infrastructure deliminating the autonomic
domain. See <xref target="I-D.behringer-autonomic-network-framework"/>
for more information.</t>
<t>The overall flow is shown in Figure 2:</t>
<t><figure>
<artwork><![CDATA[
+---------+ +----------+ +-----------+
| New | | | | Factory |
| Entity | | Domain | | Cloud |
| | | | | Service |
+---------+ +----------+ +-----------+
| | |
|<-------discovery--------->| |
|---802.1AR credential----->| |
| | |
| [ accept device? ] |
| | |
| |---802.1AR identity-------->|
| |---Domain ID--------------->|
| | |
| | [device belongs]
| | [to domain? ]
| | |
| | [update audit log]
| | |
| |<---device history log------|
| |<-- authorization token-----|
| | |
| [ still accept device?] |
| | |
|<----authorization token---| |
|<----domain information----| |
| | |
[auth token valid?] | |
| | |
|----domain enrolment------>| |
|<----domain certificate----| |
| |
]]></artwork>
</figure></t>
<section title="Behavior of a new entity">
<t>A New Entity that has not yet been bootstrapped attempts to find a
local domain and join it. A number of methods are attempted for
establishing communications with the domain in a specified order.</t>
<t>Client behavior is as follows:</t>
<t><list style="numbers">
<t>Discover a communication channel to the "closest" Registrar by
trying the following steps in this order:<list style="letters">
<t>Search for a Proxy on the local link using Neighbor
Discovery. If multiple local proxies are discovered attempt
communications with each before widening the search to other
options. If this fails:</t>
<t>Obtain an IP address using DHCP, and search for a local
registrar using DNS service discovery. If this fails:</t>
<t>Obtain an IP address using DHCP, and search for a
pre-defined Factory provided global registrar using DNS.</t>
</list></t>
<t>Present IEEE 802.1AR credentials to the discovered Registrar
(via a Proxy if necessary). Included is a generated nonce that is
specific to this attempt.</t>
<t>Verify the MASA cloud service generated authorization token as
provided by the contacted Registrar. The nonce information
previously provided is also checked, if it was not removed by the
Registrar.</t>
<t>If and only if step three is successful: Join Domain, by
accepting the domain specific information from the registrar, and
by enrolling a domain certificate from the registrar.</t>
<t>The New Entity is now a member of the domain and will only
repeat the discovery aspects of bootstrapping if it is returned to
factory default settings.</t>
</list></t>
<t>[[EDNOTE: Step (1b and 1c) is similar to the vendor DNS mechanisms
described in draft-kwatsen-netconf-zerotouch although the goal here is
to contact a Registrar rather than a vendor supplied NMS]</t>
<t>The following sections describe each of these steps in more
detail.</t>
<section anchor="ProxyDiscovery" title="Proxy Discovery">
<t>Existing protocols provide the appropriate functionality for both
discovering the Proxy and facilitating communication through the
Proxy:</t>
<t><list style="hanging">
<t hangText="IEEE 802.1X">Where the New Entity can be cast as
the "supplicant" and the Proxy is the "authenticator". The
bootstrapping protocol messages are encapsulated as EAP methods.
The "authenticator" reencapsulates the EAPOL frames and forwards
them to the "Authentication Server", which provides Registrar
functionalities.</t>
<t hangText="PANA [RFC5191]">[[EDNOTE: TBD]]</t>
<t hangText="ND [RFC2461] / [RFC4861]">[[EDNOTE: TBD]] NOTE:
Neighbor Discovery protocols do not describe a mechanism for
forwarding messages.</t>
</list>Each provides a method for the New Entity to discover and
initiate communication with a local neighbor. In each protocol
methods are available to support encapsulation of the bootstrapping
protocol messages described elsewhere in this document. Other
protocols for transporting bootstrapping messages can be added in
future references.</t>
<t>All security assocaitions established are between the new device
and the Registrar regardless of proxy operations.</t>
<t>If multiple proxies are available the New Entity tries each until
a successful bootstrapping occurs. The New Entity may prioritize
proxies selection order as appropriate for the anticipated
environment.</t>
<t>If Proxy discovery fails the New Entity moves on to discovering a
Registrar directly.</t>
</section>
<section anchor="AcceptDomain"
title="Receiving and accepting the Domain Identity">
<t>The domain trust anchor is received by the New Entity during the
boostrapping protocol exchange.</t>
<t>EST <xref target="RFC7030"/> details a set of non-autonomic
bootstrapping methods such as:</t>
<t><list style="symbols">
<t>using the Implicit Trust Anchor database (not an autonomic
solution because the URL must be securely distributed),</t>
<t>engaging a human user to authorize the CA certificate using
out-of-band data (not an autonomic solution because the human
user is involved),</t>
<t>and using a configured Explicit TA database (not an autonomic
solution because the distribution of symmetric key material is
not autonomic).</t>
</list>This document describes two additional autonomic
methods:</t>
<t><list style="hanging">
<t hangText="MASA authorization token">Authorization tokens are
obtained by the Registrar from the MASA cloud service and
presented to the New Entity for validation.</t>
<t hangText="URL redirect">If the New Entity discovers a well
known global registrar using DNS then the EST protocol exchange
is protected using an Implicit TA database, but also the MASA
authorization is required. The global registrar MUST claim the
device with the MASA server to ensure the logging information is
consistent. The global registrar forwards the New Entity to an
alternate URI as described in EST [RFC7030].</t>
</list>If these methods fail the New Entity returns to discovery
state and attempts bootstrapping with the next available discovered
Registrar.</t>
<t>[[EDNOTE: move protocol discussion down into protocol section]]
The domain trust anchor MUST be included in the TLS handshake Server
Certificate "certificate_list" [RFC5246] or the client MUST request
the EST Bootstrap Distribution of CA Certificates [RFC7030]. (This
document defines an additional method for accepting the CA
certificates).</t>
</section>
<section title="Enrollment">
<t>As the final step of bootstrapping a Registrar helps to issue a
domain specific credential to the New Entity. For simplicity in this
document, a Registrar primarly facilitates issuing a credential by
acting as an RFC5280 Registration Authority for the Domain
Certification Authority.</t>
<t>Enrollment proceeds as described in Enrollment over Secure
Transport (EST) [RFC7030]. The New Entity contacts the Registrar
using EST as indicated:</t>
<t><list style="symbols">
<t>The New Entity is authenticated using the IEEE 802.1AR
credentials [[EDNOTE: or in the non-autonomic case using the the
out of band secret].</t>
<t>The EST section 4.1.3 CA Certificates Response is verified
using the MASA authorization token provided domain identity.</t>
</list></t>
</section>
<section title="After Enrollment">
<t>Functionality to provide generic "configuration" is supported.
The parsing of this data and any subsequent use of the data, for
example communications with a Network Management System is out of
scope but is expected to occur after bootstrapping enrollment is
complete.</t>
<t>See <xref target="PostEnrollment"/>.</t>
</section>
</section>
<section title="Behavior of a proxy">
<t>The role of the Proxy is to facilitate communications. The Proxy
forwards messages between the New Entity and a Registrar. Where
existing protocols as detailed in <xref target="ProxyDiscovery"/>
already provide this functionality nothing additional is defined.</t>
<t>[[EDNOTE: If neighbor discovery protocols are used for Proxy
discovery then a proxy forwarding protocol is to be defined here]]</t>
</section>
<section title="Behavior of the Registrar">
<t>One a registrar is established it listens for new entities and
determines if they can join the domain. The registrar delivers any
necessary authorization information to the new device and facilitates
enrollment with the domain PKI.</t>
<t>Registrar behavior is as follows:</t>
<section title="Authenticating the Device">
<t>The authentication methods detailed in EST [RFC7030] are:</t>
<t><list style="symbols">
<t>the use of an IEEE 802.1AR IDevID credential,</t>
<t>or the use of a secret that is transmitted out of band
between the New Entity and the Registrar (this use case is not
autonomic).</t>
</list></t>
</section>
<section anchor="AcceptingTheEntity" title="Accepting the Entity">
<t>In a fully automated nework all devices must be securely
identified.</t>
<t>A Registrar accepts or declines a request to join the domain,
based on the authenticated identity presented and other policy
defined criteria such as Proxy identity. Automated acceptance
criteria include:</t>
<t><list style="symbols">
<t>allow any device of a specific type (as determined by the
IEEE 802.1AR device identity),</t>
<t>allow any device from a specific Factory (as determined by
the IEEE 802.1AR identity),</t>
<t>allow a specific device from a Factory (as determined by the
IEEE 802.1AR identity)</t>
</list>In all cases a Registrar must use the globally available
MASA cloud service to verify the device's history log does not
include unexpected Registrars.</t>
<t>If a device is accepted into the domain, it is then invited to
request a domain certificate through a certificate enrolment
process. The result is a common trust anchor and device certificates
for all autonomic devices in a domain. These certificates can
subsequently be used to determine the boundaries of the homenet, to
authenticate other domain nodes, and to autonomically enable
services on the homenet.</t>
</section>
<section title="Claiming the new entity">
<t>During initial bootstrapping the New Entity provides a nonce
specific to the particular bootstrapping attempt. The registrar
should include this nonce when claiming the New Entity from the MASA
cloud service. If a nonce is provided by the Registrar then claims
from an unauthenticated Registrar are serviced by the MASA cloud
resource.</t>
<t>The Registrar can claim a New Entity that is not online by
forming the request using the entities unique identifier but not
including a nonce in the claim request. MASA authorization tokens
obtained in this way do not have a lifetime and they provide a
permanent method for the domain to claim the device. Evidence of
such a claim is provided in the audit log entries available to any
future Registrar. Such claims reduce the ability for future domains
to secure bootstrapping and therefore the Registrar MUST be
authenticated by the MASA cloud service.</t>
<t>Claiming an entity establishes an audit log at the MASA server
and provides the Registrar with proof, in the form of a MASA
authorization token, that the log entry has been inserted. As
indicated in <xref target="AcceptDomain"/> a New Entity will only
proceed with bootstrapping if a validated MASA authorization token
has been recieved. The New Entity therefore enforces that
bootstrapping only occurs if the claim has been logged.</t>
</section>
</section>
<section title="Behavior of the MASA Cloud Service">
<t>The cloud service is provided by the Factory provider. The URI of
the cloud service is well known. The URI should be provided as an IEEE
802.1AR IDevID X.509 extension (a "MASA authorization token
Distribution Point" extension).</t>
<t>The cloud service provides the following functionalities to
Registrars:</t>
<section title="Issue Authorization Token and Log the event">
<t>A Registrar POSTs a claim message optionally containing the
bootstrap nonce to the MASA server.</t>
<t>If a nonce is provided the MASA cloud service responds to all
requests. The MASA cloud service verifies the Registrar is
representative of the domain and generates a privacy protected log
entry before responding with the authorization token.</t>
<t>If a nonce is not provided the MASA cloud service MUST
authenticate the Registrar as a valid customer. This prevents denial
of service attacks. The specific level of authentication provided by
the customer is not defined here. An MASA Practice Statement (MPS)
similar to the Certification Authority CPS, as defined in RFC5280,
is provided by the Factory such that Registrar's can determine the
level of trust they have in the Factory.</t>
</section>
<section title="Retrieve Audit Entries from Log">
<t>When determining if a New Entity should be accepted into a domain
the Registrar retrieves a copy of the audit log from the MASA cloud
service. This contains a list of privacy protected domain identities
that have previously claimed the device. Included in the list is an
indication of the time the entry was made and if the nonce was
included.</t>
</section>
</section>
<section anchor="PostEnrollment"
title="Leveraging the new key infrastructure / next steps">
<t>As the devices have a common trust anchor, device identity can be
securely established, making it possible to automatically deploy
services across the domain in a secure manner.</t>
<t>Examples of services:<list style="symbols">
<t>Device management.</t>
<t>Routing authentication.</t>
<t>Service discovery.</t>
</list></t>
<section title="Network boundaries">
<t>When a device has joined the domain, it can validate the domain
membership of other devices. This makes it possible to create trust
boundaries where domain members have higher level of trusted than
external devices. Using the autonomic User Interface, specific
devices can be grouped into to sub domains and specific trust levels
can be implemented between those.</t>
</section>
</section>
</section>
<section title="Protocol Details">
<t>The bootstrapping protocol is an extension of EST [RFC7030].</t>
<t>[[EDNOTE: Insert figure here]]</t>
<t>EST provides a bootstrapping mechanism for new entities that are
configured with the URI of the EST server or new entities that can
"engage a human user to authorize the CA certificate using out-of-band
data such as a CA certificate". EST does not provide a completely
automated method of bootstrapping the PKI. [[EDNOTE: This paragraph
should be expanded to provide a detailed discussion of current EST
functionalitites, or do we assume the reader follows the normative
reference?]].</t>
<t>The following additions provide for fully automated functionality.
EST is extended by defining additional HTTP URIs and messages specific
to bootstrapping. These are optionally supported by the EST server
within the same .well-known URI tree as the existing EST URIs.</t>
<t>The "New Entity" is the EST client and the "Registrar" is the EST
server.</t>
<section title="EAP-EST">
<t>In order to support Proxy environments EAP-EST is defined.</t>
<t>[[EDNOTE: TBD. EST is TLS with some data. EAP-TLS and other similar
protocols provide an example framework for filling out this
section]]</t>
</section>
<section title="Request bootstrap token">
<t>When the New Entity reaches the EST section 4.1.1 "Bootstrap
Distribution of CA Certificates" state but wishes to proceed in a
fully automated fashion it makes a request for a MASA authorization
token from the Registrar.</t>
<t>This is done with an HTTPS POST using the operation path value of
"/requestbootstraptoken".</t>
<t>The request format is a raw nonce value. [[EDNOTE: exact format
TBD. There is an advantage to having the client sign the nonce
(similar to a PKI Certification Signing Request) since this allows the
MASA cloud service to confirm the actual device identity. It is not
clear that there is a security benefit from this.]]</t>
<t>The Registrar validates the client identity as described in EST
[RFC7030] section 3.3.2. The registrar performs authorization as
detailed in <xref target="AcceptingTheEntity"/>. If authorization is
successful the Registrar obtains a MASA authorization token from the
MASA cloud service (see <xref target="RequestAuthzToken"/>).</t>
<t>The recieved MASA authorization token is returned to the New
Entity.</t>
<t>[[EDNOTE: update to CMS language]]</t>
</section>
<section anchor="RequestAuthzToken"
title="Request MASA authorization token">
<t>A registrar requests the MASA authorization token from the cloud
service using this EST extension.</t>
<t>This is done with an HTTP POST using the operation path value of
"/requestMASAauthorization".</t>
<t>The request format is an optional raw nonce value (as obtained from
the bootstrap request) and the IEEE 802.1AR identity of the device as
a serial number (the full certificate is not needed and no
proof-of-possession information for the device identity is included).
This information is encapsulated in a PKCS7 signed data structure that
is signed by the Registrar. The entire certificate chain, up to and
including the Domain CA, is included in the PKCS7.</t>
<t>The MASA cloud service checks the internal consistency of the PKCS7
but is unable to actually authenticate the domain identity
information. The domain is not know to the MASA server in advance and
a shared trust anchor is not implied. The MASA server verifies that
the PKCS7 is signed by a Registrar (by checking for the cmc-idRA field
in the Registrar certificate) certificate that was issued by the root
certificate included in the PKCS7.</t>
<t>The domain ID is extracted from the root certificate and is used to
generate the MASA authorization token and to update the audit log.</t>
<t>[[EDNOTE: update to CMS language]]</t>
</section>
<section title="Request MASA authorization log">
<t>A registrar requests the MASA authorization log from the cloud
service using this EST extension.</t>
<t>This is done with an HTTP GET using the operation path value of
"/requestMASAlog".</t>
<t>The log data returned is a file consisting of each log entry. The
data in each entry includes:</t>
<t><list style="symbols">
<t>date/time of the entry</t>
<t>domain ID (this is just a hash of the public key information
and is thus privacy protected)</t>
<t>nonce value</t>
</list>[[EDNOTE: exact format TBD]]</t>
</section>
</section>
<section title="Reduced security operational modes">
<t>A common requirement of bootstrapping infrastructures is often that
they support less secure operational modes. To support these operational
modes the Registrar can choose to accept devices using less secure
methods. For example:</t>
<t><list style="numbers">
<t>The registrar may chose to accept all devices, or all devices of
a particular type, at the administrator's discretion. This may occur
when: Informing the Registrar of unique identifiers of new entities
might be operationally difficult.</t>
<t>The registrar may chose to accept devices that claim a unique
identity without the benefit of authenticating that claimed
identity. This may occur when: The New Entity does not include an
IEEE 802.1AR factory installed credential.</t>
<t>A representative of the Registar (e.g. the Orchestrator) may
request nonce-less authorization tokens from the MASA cloud service
when network connectivity is available. These tokens can then be
transmitted to the Registrar and stored until they are needed during
bootstrapping operations. Ths may occur when: The target network is
protected by an air gap and therefore can not contact the MASA cloud
service during New Entity deployment.</t>
<t>The device may have an operational mode where it skips
authorization token validation. For example if a physical button is
depressed during the bootstrapping operation. This may occur when: A
device Factory goes out of business or otherwise fails to provide a
reliable MASA cloud service.</t>
<t>The device may not require the MASA cloud service authorization
token. An entity that does not validate the domain identity is
inherently dangerous as it may contain malware. This risk should be
mitigated using attestation and measurement technologies. In order
to support an unsecured imprint the New Entity MUST support remote
attestation technologies such as is defined by the Trusted Computing
Group. [[EDNOTE: How to include remote attestation into the
boostrapping protocol exchange is TBD]]. This may occur when: The
device Factory does not provide a MASA cloud service.</t>
</list></t>
</section>
<section title="Security Considerations">
<t>In order to support a variety of use cases, devices can be claimed by
a registrar without proving possession of the device in question. This
would result in a nonceless, and thus always valid, claim. The MASA
cloud service is required to authenticate such Registrars but no
programatic method is provided to ensure good behavior by the MASA cloud
service. Nonceless entries into the audit log therefore permanently
reduce the value of a device because future Registrars, during future
bootstrap attempts, must now be configured with policy to ignore
previously (and potentially unknown) domains.</t>
<t>Future registrars are recommended to take the audit history of a
device into account when deciding to join such devices into their
network.</t>
<t>It is possible for an attacker to send an authorization request to
the MASA cloud service directly after the real Registrar obtains an
authorization log. If the attacker could also force the bootstrapping
protocol to reset there is a theoretical opportunity for the attacker to
use the authorization token to take control of the New Entity but then
proceed to enrol with the target domain. To prevent this the MASA cloud
service is rate limited to only generate authorization tokens at a rate
of 1 per minute. The Registrar therefore has at least 1 minute to get
the response back to the New Entity. [[EDNOTE: a better solution can
likely be found. This text captures the issue for now.]] Also the
Registar can double check the log information after enrolling the New
Entity.</t>
<t>The MASA cloud service could lock a claim and refuse to issue a new
token. Or the MASA cloud service could go offline (for example if a
vendor went out of business). This functionality provides benefits such
as theft resistance, but it also implies an operational risk. This can
be mitigated by Registrars that request nonce-less authorization
tokens.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC7030;
<reference anchor="IDevID"
target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
<front>
<title>IEEE 802.1AR Secure Device Identifier</title>
<author surname="IEEE Standard"/>
<date month="December" year="2009"/>
</front>
</reference>
</references>
<references title="Informative References">
&I-D.behringer-autonomic-network-framework;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:03:38 |