Operational Considerations for Manufacturer Authorized Signing Authority
draft-richardson-anima-masa-considerations-01

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Author Michael Richardson 
Last updated 2019-12-04 (latest revision 2019-12-03)
Stream (None)
Intended RFC status (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
anima Working Group                                        M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Standards Track                       December 04, 2019
Expires: June 6, 2020

Operational Considerations for Manufacturer Authorized Signing Authority
             draft-richardson-anima-masa-considerations-01

Abstract

   This document describes a number of operational modes that a BRSKI
   Manufacturer Authorized Signing Authority (MASA) may take on.

   Each mode is defined, and then each mode is given a relevance within
   an over applicability of what kind of organization the MASA is
   deployed into.  This document does not change any protocol
   mechanisms.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 6, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Richardson                Expires June 6, 2020                  [Page 1]
Internet-Draft             MASA Considerations             December 2019

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Operational Considerations for Manufacturer IDevID Public Key
       Infrastructure  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  On-device private key generation  . . . . . . . . . . . .   4
     2.2.  Off-device private key generation . . . . . . . . . . . .   4
     2.3.  Public Key infrastructure for IDevID  . . . . . . . . . .   5
   3.  Operational Considerations for Manufacturer Authorized
       Signing Authority (MASA)  . . . . . . . . . . . . . . . . . .   5
     3.1.  Self-contained multi-product MASA . . . . . . . . . . . .   6
     3.2.  Self-contained per-product MASA . . . . . . . . . . . . .   7
     3.3.  Per-product MASA keys intertwined with IDevID PKI . . . .   7
     3.4.  Rotating MASA authorization keys  . . . . . . . . . . . .   8
   4.  Operational Considerations for Constrained MASA . . . . . . .   9
   5.  Operational Considerations for creating Nonceless vouchers  .   9
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [I-D.ietf-anima-bootstrapping-keyinfra] introduces a mechanism for
   new devices (called pledges) to be onboarded into a network without
   intervention from an expert operator.

   This mechanism leverages the pre-existing relationship between a
   device and the manufacturer that built the device.  There are two
   aspects to this relationship: the provision of an identity for the
   device by the manufacturer (the IDevID), and a mechanism which
   convinces the device to trust the new owner (the [RFC8366] voucher).

   The manufacturer, or their designate, is involved in both aspects of
   this process.  This requires the manufacturer to operate a
   significant process for each aspect.

   This document offers a number of operational considerations for each
   aspect.

Richardson                Expires June 6, 2020                  [Page 2]
Internet-Draft             MASA Considerations             December 2019

   The first aspect is the device identity in the form of an
Show full document text