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

From: Toerless Eckert <[email-masked]>
Date: Tue, 13 Dec 2016 17:59:03 +0100

Hi Max, *:

Wrt to the new text you are trying to work out for voucher terminology,
that is captured in todays notes on the etherpad:

I think that the voucher terminology will be confusing as long
as the name "audit" (voucher) implies the use of a public key (line 144
in etherpad), and the "ownership" (voucher) implies the use of
a certificate (via DN of certificate). audit vs. ownership are
just describing the type of assertion. Whether i want to use
public-key or Cert-DN is IMHO orthogonal (i think we already allow
that in the voucher draft), and it could help if we are also
clearer in the language.

Aka: 
  - classical anima voucher, call it:   public key audit voucher
  - classical netconf voucher, call it: certificate ownership voucher

  - Can i have a certificate audit voucher ? Absolutely!
  - Can i have a public key ownersip voucher ? Absolutely!
  - Can i have a certificate or public key  audit AND ownership voucher ?
    I think yes, but that would be icing on the cake.
    
Which IMHO leaves to explain the differences semantically:
- ownership vs. audit i think is simple
  - ownership: strong assertion by vendor. Can be pricy to support by vendor.
  - audit: lightweight assertion by vendor.

- certificate vs. public key
  - low end solutions may want to be lightweight and not rely fully
    on a certificate system. Just using public key is more lightweight.
  - Even if a system wants to use certificates, relying only on
    public key decouples enrolment from PKI. Aka: more modular design:
    use public key enrolment, and use normal PKI Cert enrolment afterwards
    (using the trust relationship established via the public key). This
    is the option that ANIMA chooses because EST already provides such
    a standalone enrolment method.
  - 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).
  - If vouchers are handled "offline" shipped via sneakernet/usb-sticks
    vendor->registrar in a solution where certificates are used (all
    the way into the pledge), certificate vouchers are the complete data
    needed. public key vouchers would require the certificate data to
    be encoded on the side too.

Hope all four are correct. Thats high level how i'd try to explain the
difference. Even if not correct, i hope it makes sense trying to figure
out these type of explanations of differences in the choices our voucher
solution offers.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Dec 2016 14:50:33 -0500

Toerless Eckert <[email-masked]> wrote:
    > I think that the voucher terminology will be confusing as long as the
    > name "audit" (voucher) implies the use of a public key (line 144 in
    > etherpad), and the "ownership" (voucher) implies the use of a
    > certificate (via DN of certificate). audit vs. ownership are just

I agree.

I also think that the audit promise is orthogonal to how the owner is
indicated.  It might be that all combinations are not useful, but I'd like to
enumerate them anyway.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Dec 2016 14:56:48 -0500

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 19 Dec 2016 22:18:37 +0000

Take a look at the pre v5 version I’ve posted. Section 2.2 includes the following:
https://github.com/ietf-roll/anima-bootstrap/blob/master/dtbootstrap-anima-keyinfra-05.txt

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
      service.

   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 <[email-masked]> wrote:
> 
>