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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Author Michael Richardson 
Last updated 2019-12-05 (latest revision 2019-12-04)
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                         5 December 2019
Expires: 7 June 2020

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

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 7 June 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

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

   as described in Section 4.e of 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 . . . . . . . . . . . .   7
     3.2.  Self-contained per-product MASA . . . . . . . . . . . . .   7
     3.3.  Per-product MASA keys intertwined with IDevID PKI . . . .   8
     3.4.  Rotating MASA authorization keys  . . . . . . . . . . . .   9
   4.  Operational Considerations for Constrained MASA . . . . . . .   9
   5.  Operational Considerations for creating Nonceless vouchers  .  10
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

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 7 June 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