Re: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round

"Max Pritikin (pritikin)" <> Mon, 19 December 2016 22:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E4A6129423 for <>; Mon, 19 Dec 2016 14:18:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.622
X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Hu8PqqQARrr for <>; Mon, 19 Dec 2016 14:18:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EE96129422 for <>; Mon, 19 Dec 2016 14:18:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9480; q=dns/txt; s=iport; t=1482185919; x=1483395519; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xbdfO48EBuGQWoHlrAaPEnSpP2UcbfABqmFpOxgF9EE=; b=YwzMcxpyH8GzppKZ9FPgLSf0H/7EuBJyigfGeUm6aS40UtQ1zu6HfIFL k9ggLx8Wzyn6IHU/s/9MCIKabh5o4FF00l/2UBMaEnkDZN6mwFzwnyiw9 1Tzsb0xLWtifgIROjq+qujhRBwJHOzyUkBhUoMZuzSwtXQEsSvZ3JxMMa Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.33,375,1477958400"; d="scan'208";a="363114228"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2016 22:18:38 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uBJMIcmt024789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2016 22:18:38 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Dec 2016 16:18:37 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 19 Dec 2016 16:18:37 -0600
From: "Max Pritikin (pritikin)" <>
To: Michael Richardson <>, Toerless Eckert <>
Thread-Topic: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round
Date: Mon, 19 Dec 2016 22:18:37 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Dec 2016 22:18:41 -0000

Take a look at the pre v5 version I’ve posted. Section 2.2 includes the following:

Does this help?

- max

2.2.  Secure Imprinting using Vouchers

   A voucher is a cryptographically protected statement to the Pledge
   device indicating authorizing a zero-touch imprint on the Registrar
   domain.  Generically the voucher imparts the following information to
   the Pledge:

   Assertion Basis  Indicates the method that protects the imprint.
      This might include discrete ownership verification, assured
      logging operation or reliance on Pledge endpoint behavior such as
      secure root of trust of measurement.  Only some methods are
      normatively defined in this document.  Other methods are left for
      future work.

   Registrar Authentication  Indicates how the Pledge can authenticate
      the Registrar.  This might include an indication of the PKIX trust
      anchor used by the Registrar, or an indication of shared PKIX
      trust anchor and additional CN-ID or DNS-ID information to
      complete authentication.  Symetric key or other methods are left
      for future work.

   Anti-Replay Protections  Time or nonce based information constrain
      vouchers to time periods or bootstrap attempts.

   A number of boostrapping scenarios can be met using differing
   combinations of this information.  All scenarios address the primary
   threat of a MiTM Registrar gaining control over the Pledge device.
   The primary voucher combinations are referred to within this document
   by name:

                |Assertion   |Registrar ID    |Pledge ID | Validity    |
                |Log-|Veri-  |Trust  |CN-ID or|serial    | RTC | Nonce |
                | ged|  fied |Anchor |DNS-ID  |number    |     |       |
   Audit        |  X |       | X     |        | X        |     | X     |
   Nonceless    |  X |       | X     |        | X        |     |       |
   Audit        |    |       |       |        |          |     |       |
   Owner Audit  |  X |   X   | X     |        | X        |     | X     |
   Owner ID     |    |   X   | ?     |  X     | X        | X   |       |
   BearerVoucher|  X |       |   wildcard     | X        | ?           |
   MasterVoucher|    |       |   wildcard     | wildcard | X   |       |

Pritikin, et al.          Expires June 22, 2017                [Page 11]
Internet-Draft                   BRewSKI                   December 2016

   Audit Voucher  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

   Nonceless Audit Voucher  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 partions or to
      provide a permanent voucher for remote deployments.

   Ownership Audit Voucher  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 suppliment the MASA.  This provides an ideal sharing of policy
      decisions and enforcement between the vendor and the owner.

   Ownership ID Voucher  An Ownership ID Voucher is named after
      inclusion of the Pledge's CN-ID or DNS-ID within the voucher.  An
      example Ownership Voucher is defined in
      [I-D.ietf-netconf-zerotouch].  The MASA service mitigates a MiTM
      Registrar by identifying the specific Registrar authorized to own
      the Pledge.

   Bearer Voucher  A Bearer Voucher is named after the inclusion of a
      Registrar ID wildcard.  Because the Registrar is not specifically
      identified this voucher type must be treated as a secret and
      protected from exposure as any 'bearer' of the voucher can claim
      the Pledge device.  Theoretically "nonced" and "nonceless" bearer
      vouches can exist.  Publishing a nonceless bearer voucher
      effectively turns the specified Pledge into a "TOFU" device with
      minimal mitigation against MiTM Registrars.

   Master Voucher  A Master Voucher is named after the inclusion of a
      Pledge ID wildcard.  Because the Pledge is not specifically
      identified publishing a nonceless Master Voucher would turn all
      Pledges that trust the MASA into TOFU devices.  This would be a
      significant security consideration as it puts too much power in
      the hands of the vendor MASA service.  Wildcard Pledge IDs MUST
      NOT be accepted.

   [[EDNOTE: Exact definitions of Assertion, ID and Validity methods
   come from the voucher document.  Included are normative statements on
   how Registrar and Pledge operate on these informations after
   verifying the voucher]]

> On Dec 17, 2016, at 12:56 PM, Michael Richardson <> wrote:
> Toerless Eckert <> wrote:
>> - Including certificate in the voucher allows those vouchers to
>> lie around at an owner much longer. Their validity is as long as that
>> of the included CA certificate (eg: >= 10 years). The validity of
>> a public key is typically much shorter (eg: <= 1 year).
> A certificate is valid as long as the CA that vouches for the DN renews
> the certificate.  They keys can be renewed, and algorithms can even be
> replaced.  That's the payoff from the overhead of the PKI.
> => This is what we need to capture into the document.
> A public key has no expiry date, since it has no date associated with it.
> When you say that a public key is "typically" shorter, you are really
> expressing a good crypto-hygiene suggestion to the owner of the public.
> --
> Michael Richardson <>, Sandelman Software Works
> -= IPv6 IoT consulting =-