Subject: [Anima] What does PKIX refer to: Re: Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Aug 2019 14:15:49 -0400

I hoping for some discussion about this comment that I previously
responded to, but it probably got buried.

    > Section 2.3

    > Pledge authentication and pledge voucher-request signing is via a
    > PKIX certificate installed during the manufacturing process.  This is

    > (As noted elsewhere, "PKIX" may not be the best term here.)

...

    > (10) The term PKIX seems to be incorrectly used a few times; it refers
    > to the Internet PKI, and so things like a private PKI internal to a
    > manufacturer would probably not be best described as such.  Such
    > private PKIs can of course still reuse the protocols and mechanisms
    > developed for PKIX, and it's accurate to describe them as such.

I would never call the Internet PKI "PKIX".
I'd call it WebPKI, or CAB.

PKIX is the set of IETF specifications that made X509v3 useful.

(I try never to use "X509", because the ITU left us with an unuseable
mess, and I don't think they deserve any credit)

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Aug 2019 14:24:51 -0400

> responded to, but it probably got buried.

Actually, you did respond on July 20, in an email that I thought to re-read
after pushing send.

In it you said:

mcr> I would never call the Internet PKI "PKIX".
mcr> I'd call it WebPKI, or CAB.
mcr> PKIX is the set of IETF specifications that made X509v3 useful.
mcr> (And why I try never to use "X509"...)
mcr>
mcr> I couldn't find a reference to private PKI, so maybe I mis-understand.

   doc> This document details protocols and messages to answer the above
   doc> questions.  It uses a TLS connection and an PKIX (X.509v3)
   doc> certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
   doc> points 1 and 2.  It uses a new artifact called a "voucher" that the
   doc> [...]
   doc> Pledge authentication and pledge voucher-request signing is via a
   doc> PKIX certificate installed during the manufacturing process.  This is

bk> The comment about private PKI was me making an assumption; I could be
bk> wrong.  But I don't really expect all manufacturers that do this to have
bk> their IDevID signing CA be part of the Internet PKI; I expect them to be
bk> standalone CAs with the root baked into hardware and nothing else that
bk> uses that root.  Does that help clarify?

It helps to clarify where you think I'm referring to the Internet PKI.

I don't think of "PKIX" as referring to the Internet PKI/WebPKI as managed by
the CAB-Forum.  Yes, it will be a private CA 96% of the time.
A 1988 era X509v3 certificate isn't good enough; it has to be the IETF PKIX
WG profile of X509v3.  801.1AR mostly says that.

If you feel that my use of PKIX here is too confusing, I will change it.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Aug 2019 13:51:43 -0500

> WG profile of X509v3.  801.1AR mostly says that.

I mean, PKIX closed before I was really doing much of anything in the IETF,
so all I have are vague impressions shaped by what I've picked up from
inferences made observing discourse among others.  So I did have to check
with someone who was actually there to confirm my sense that PKIX is the
Internet PKI.  (Not SPKI!)  And sure, anything can be connected to the
Internet, and presumably the BRSKI cases will be talking to the MASA over
the Internet in some fashion, but it's hard to say that the PKI used to do
so is a core part of the capital-I Internet.

> If you feel that my use of PKIX here is too confusing, I will change it.

I'm still open to pushback, but something like "PKIX-compatible" or
"PKIX-conformant" would make me happier.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Aug 2019 16:17:17 -0400

https://tinyurl.com/yylruorn contains a diff against -24.

Benjamin Kaduk via Datatracker <[email-masked]> wrote:
    > [disclaimer: some of these comments get pretty blunt at the end; it's a
    > long document and I'm tired.  Please try not to get too annoyed if I'm
    > failing to see something that's right in front of me.]

    > I concur with the directorate reviewers that expected a
    > high-level security analysis of what information flows where, and what
    > policy choices can be made that affect it.  At a *very* high level
    > (skipping over a lot of things that I would expect to see), this would
    > be structured like:

    > On initial bootstrap, a new device uses local service autodiscovery to
    > locate a (proxy to a) local registrar.  Having found a candidate

I have included an edited version of this text. It was very well done, thank
you!

    > Abstract

    > (side note?) Is there a quick explanation of why bootstrapping can
    > complete with just installation of the PKI (trust anchor?) and
    > provisioning a locally issued certificate is not mandatory?

I don't think that we can fit a quick explanation into the Abstract.
I did split up the last sentence.

The hard thing that BRSKI provides is the trust of the network by the pledge.
The trust of the device by the network is generally an "easy" problem solved
by use of 802.1AR/IDevID. This is presently done in many existing EST and CMP
users.
So I'm not sure what further to do here.

    > Section 1

    > This document describes how pledges discover (or be discovered by) an
    > element of the network domain to which the pledge belongs to perform
    > the bootstrap.  [...]

    > nit: s/be/are/, IIUC.
    > I think there's also something funky with the wording of "to perform the
    > bootstrap"; we may be looking for an element "that will perform the
    > bootstrap".

yes, done.

    > 4.  Pledge authorizing the registrar: "Should I join it?"

    > nit: what is "it"?  Surely not the registrar, and presumably the
    > "network domain" in question?

yes, it = "network"

    > This document details protocols and messages to answer the above
    > questions.  It uses a TLS connection and an PKIX (X.509v3)
    > certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
    > points 1 and 2.  It uses a new artifact called a "voucher" that the

    > I'm kind of confused by "[IDevID] LDevID", since my understanding was
    > that the LDevID is issued only after all four steps are complete.

Yes, that seems to be a typo.

    > Also, following the IDevID link lands me at a page that claims to be for
    > a standard of status "superseded".

Yes, the IEEE apparently put out 802.1AR-2018 replacing -2009 last year.
I don't have a copy, and the getieee program just goes in loops of logging
in, or results in servlet errors.
I even emailed support, and they were basically useless.
{fetching coffee to avoid rant}

    > nit: one can use X.509v3 without being PKIX, and it's not entirely clear
    > that the IDevIDs will chain up to the Internet PKI.

You didn't respond to my suggestion that PKIX!=Internet PKI.
I do think that we want many things the IETF PKIX WG has produced
since X.509v3, so I don't think that X.509v3 is an appropriate noun
to describe things.

    > Section 1.2

    > RFC 8174 has an updated version of the BCP 14 boilerplate.

done already.

    > I'd suggest adding "MASA Audit Log" as a defined term to give advance
    > warning that this is an explicit protocol feature.

added.

    > domainID:  The domain IDentity is the 160-bit SHA-1 hash of the BIT
    > STRING of the subjectPublicKey of the pinned-domain-cert leaf,
    > i.e. the Registrars' certificate.  This is consistent with the
    > subject key identifier (Section 4.2.1.2 [RFC5280]).

    > What would it take to move away from SHA-1 for this purpose?  It's
    > unclear how long it will be before finding a second preimage of the SPKI
    > hash is feasible and thus using it as an identifier no longer serves to
    > uniquely identify something.

This was asked by Eric as well.
It's the Subject Key Identifier that we want.
     https://tools.ietf.org/html/rfc5280#section-4.2.1.2

It's only guaranteed to exist in CA certificates.
Do you think we can demand that the extension be present in IDevID?
If so, we could just use that value in the MASA Audit Log.
But, if we did, it would often still be the SHA-1 hash of the public key, but
RFC5280 says:
        "Other methods of generating unique numbers are also acceptable."

When https://tools.ietf.org/html/rfc5758 defined SHA-2 usage,
it didn't specify a way to identify keys with SHA-2, although the mechanism
is pretty clear.

    > enrollment:  The process where a device presents key material to a
    > network and acquires a network specific identity.  For example

    > nit: hyphenate "network-specific".

ok.

    > Section 1.4

    > As a result of the protocol described herein, the bootstrapped
    > devices have the Domain CA trust anchor in common.  An end entity
    > certificate has optionally been issued from the Domain CA.  [...]

    > This end-entity certificate is supposed "to authenticate each
    > bootstrapped device to other parties in the domain", right?

    > The major beneficiary is that it possible to use the credentials
    > deployed by this protocol to secure the Autonomic Control Plane (ACP)
    > ([I-D.ietf-anima-autonomic-control-plane]).

    > I might humbly suggest "major intended beneficiary", as there seem to be
    > many possibilities involving BRSKI.

ok

    > Section 1.5

    > The pledge must perform discovery of the proxy as described in
    > Section 4.1 using GRASP M_FLOOD announcements.

    > Is this DULL GRASP or full-on ACP GRASP flooding?

DULL GRASP, word inserted.

    > Upon successfully validating a voucher artiface, a status telemetry
    > MUST be returned.  See Section 5.7.

    > nit: artifact (right?)

previously fixed.

    > The ANI Join Registrar ASA MUST support all the BRSKI and above
    > listed EST operations.

    > nit: probably need to expand ASA the first time.

done.

    > Section 2

    > The text following Figure 1 suggests that the Domain Registrar is not
    > always (also) a PKI RA, but the parentheticals in the figure itself are
    > easy to read as a clarification and not an optional thing, especially
    > since parentheticals are used in a different manner for the Key
    > Infrastructure box.

text:      Optionally the registrar also acts as a PKI Registration
           Authority.

I think that the text should read:
           Optionally the registrar also acts as a PKI Certification
           Authority.

    > Section 2.1

    > 3.  Request to join the discovered registrar.  A unique nonce is
    > included ensuring that any responses can be associated with this
    > particular bootstrapping attempt.

    > But the nonce is not always present!

I have been thinking hard about this problem, and I agree it is hard to
understand here.  Part of the issue is that the decision as to when and how
to accept nonceless non-expiring ("offline") vouchers is a complex question,
but it's also a private decision between the manufacturer's MASA and
the manufacturer's device.

The non-expiring nonceless voucher is a bit like kryptonite: once the
manufacturer signs such a thing, it pretty much trumps everything else.

I think that we need to add a section on nonce-less offline operation.

    > 5.  Enroll.  After imprint an authenticated TLS (HTTPS) connection
    > exists between pledge and registrar.  Enrollment over Secure
    > Transport (EST) [RFC7030] is then used to obtain a domain
    > certificate from a registrar.

    > Isn't this step optional?

so, I can change the word to "can" rather than "is"

    > Section 2.2

    > A voucher is a cryptographically protected artifact (a digital
    > signature) to the pledge device authorizing a zero-touch imprint on
    > the registrar domain.

    > nit: "using a digital signature"

ok.

    > Vouchers provide a signed but non-encrypted communication channel
    > among the pledge, the MASA, and the registrar.  The registrar
    > maintains control over the transport and policy decisions allowing
    > the local security policy of the domain network to be enforced.

    > nit: is there supposed to be a comma after "policy decisions" (in that
    > both the transport and policy decisions allow for policy enforcement)?

okay.

    > 1.  Uniquely identifying the pledge by the Distinguished Name (DN)
    > and subjectAltName (SAN) parameters in the IDevID.  The unique
    > identification of a pledge in the voucher objects are derived
    > from those parameters as described below.

    > These unique identifiers can (by design) be used for tracking, so let's
    > be sure that we talk about any privacy considerations with them, later.
    > I see a mention in passing in Section 10.2, at least...

Are you asking for a forward reference to 10.2?  I will add this.
I think that section 10.2 is pretty clear about this.
I don't think it's mentioned just in passing.

    > 3.  Secure auto-discovery of the pledge's MASA by the registrar (see
    > Section 2.8).

    > I don't think this is an ironclad property, since the crypto chain is
    > slightly limited and you are in effect trusting the pledge to hand you
    > something that says "use this issuer" but without as much crypto to back
    > that up as we might want.  We have to know that the given manufacturer
    > that signed the IDevID actually is associated with the device we're
    > trying to bootstrap, which can probably be arranged but I don't remember
    > being called out explicitly.

There are two issues here.

One is the question of what is the list of acceptable manufacturers (below).
The second part is whether a pledge could provide a fake IDevID to
the Registrar.  The pledge is doing TLS ClientCertificate, so the TLS
has proven that the pledge has the private key corresponding to the
certificate presented.  I conclude that an arbitrary IDevID can not be
provided by the Pledge; it has to be linked to SOME manufacturer. Some
manufacturer A could point it's product at MASA B, but I don't see how this
is an issue if MASA B will issues vouchers that pledge A can verify.

(The pledge could have a variety of certificates from
a variety of sources, perhaps all bound to the same public key, I guess, and
since the Registrar sends it's certificate first, the pledge could present
different identities to different networks. I think that this is a feature,
not a bug.  It reminds that "Kenmore" brand appliances were made by a variety
of manufacturers, but I don't see my dishwasher can know what identity
to use until after there is communication with the MASA)

The question then becomes how the Registrar comes to trust/verify the
pledge's IDevID.  We had a long discussion about this during the directorate
reviews and going back to Feb. 2018.  I thought that we resolved this.
Issues
  https://github.com/anima-wg/anima-bootstrap/issues/120
  https://github.com/anima-wg/anima-bootstrap/issues/43
  https://github.com/anima-wg/anima-bootstrap/issues/46
A thread starts here:
  https://mailarchive.ietf.org/arch/msg/anima/p7pUw1HKq6Ot0gV8JPeRWhwvQTs

Some changes that we made for this:
  https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc703626012d62c0b3138d851b61a2f54

    > Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage
    > extensions in the IDevID certificate.  Any restrictions included

    > I only got my hands on the 2018 rev of [IDevID], but that one does not
    > actually talk about extendedKeyUsage.

Max was the editor of the 2009 edition, and we pointed at it.
I don't seem to be able to get the 2018 edition.

7.2.13:

  7.2.13 extensions

  The optional extensions field defined in RFC 5280 shall not be used for
  critical extensions in any IDevID credential with the exception of the
  keyUsage extension. The non-critical extensions included are specified
  in 7.2.5 (authorityKeyIdentifier) and 7.2.9 (subjectAltName).
  The key usage field defined in RFC 5280 is intended to restrict the
  associated key material to only the
  specified usages. The intention of an IDevID is to provide a long lived
  credential useful for identifying the
  device in any future protocol uses. Restrictions applied during issuance may
  limit the future usefulness of
  the DevID. If a critical keyUsage extension is included in the IDevID, it
  shall include digitalSignature as
  defined in RFC 5280. The keyUsage extension may include keyEncipherment.
  The optional extensions field defined in RFC 5280 should not be used for
  critical extensions in any LDevID
  credential. As specified in RFC 5280 a network solution that uses the LDevID
  credentials and encounters a
  critical extension it does not understand will signal an error and fail
  validation of the LDevID credential.

I don't know why this advice against EKU is gone from the 2018 edition.

    > Section 2.3.1

    > In the context of BRSKI, pledges are uniquely identified by a
    > "serial-number".  This serial-number is used both in the "serial-
    > number" field of voucher or voucher-requests (see Section 3) and in
    > local policies on registrar or MASA (see Section 5).

    > (editorial) if the IDevID is supposed to be a unique identifier, why do
    > we need another one?

The pledge extracts it from it's IDevID.
The registrar extracts it again from the IDevID that it sees.
It's seems hard to construct an attack where the provisional TLS connection
is MITM (replacing the certificates). So I'm gonna claim belt-and-suspenders
here.... the cross-check seems useful, but maybe in the end, it's a left-over
From when voucher-requests could be unsigned.

    > o  The subject field's DN encoding MUST include the "serialNumber"
    > attribute with the device's unique serial number.  (from [IDevID]
    > section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard
    > attributes)

    > side note: I had to think a  bit to convince myself that DN is the right
    > thing here; when we use dnsNames it's preferred to put them in
    > subjectAltName to avoid having to pick a preferred/privileged one, but
    > the serial number does seem to be in a privileged position for
    > distinguishing the subject.

The dnsNames are hard to use when we have no FQDN to attach to :-)

    > o  The subject-alt field's encoding MAY include a non-critical
    > version of the RFC4108 defined HardwareModuleName.  (from [IDevID]
    > section 7.2.9) If the IDevID is stored in a Trusted Platform
    > Module (TPM), then this field MAY contain the TPM identification
    > rather than the device's serial number.  If both fields are
    > present, then the subject field takes precedence.

    > "if both fields are present", but the subject field MUST be present, so
    > this field can never take precedence.

I'm willing to drop, because I never got proper clarification.
We were told by implementors that if the IDevID is contained in a TPM that
the resulting IDevID often has the serialNumber of the TPM,not the device
itself.

*** MAX ***

    > 1.  [RFC4519] section 2.31 provides an example ("WI-3005") of the
    > Distinguished Name "serialNumber" attribute.  [RFC4514] indicates
    > this is a printable string so no encoding is necessary.

    > I don't understand why these references were chosen.  Why are LDAP specs
    > authoritative about what the encoding format for the serialNumber DN
    > attribute is?  E.g., one could look at RFC 5280 to see that
    > X520SerialNumber is a PrintableString.

*** MAX ***

    > 2.  The HardwareModuleName hwSerialNum OCTET STRING.  This value is
    > base64 encoded to convert it to a printable string format.

    > Please cite Section 4 of RFC 4648 (unless you mean base64url, in which
    > case use Section 5).
    > Also, it might be nice to somehow (maybe enumerate the first list in the same
    > way) tie these two items to the respective subject ND/subjectAltName
    > fields, to clarify why these are the only two choices.

    > As explained in Section 5.5 the Registrar MUST extract the serial-
    > number again itself from the pledge's TLS certificate.  [...]

    > To be clear, this is still the device's IDevID certificate, that just
    > happens to be getting used as a TLS client certificate.

Yes, that's right.

    > Section 2.3.2

    > nit: maybe put a blank line after the IMPORTS are over?

done.

    > Section 2.4

    > In Figure 3, I had to think a bit to figure out whether the text that
    > did not fit mid-arrow was supposed to apply to the arrow above or below
    > the text (e.g., "optional: mDNS query RFC6763/RFC6762").

Yes... we did struggle to fit it into a single page.
It applies to both the arrow above and below, and there are M_FLOOD
and mDNS possible here.  Do you have suggestions on making it clearer.

    > [Hmm, so we send our TLS client cert on the provisional connection,
    > meaning that we have to trust the proxy and registrar to be doing the
    > right thing w.r.t. broadcasting our identity to the world]

Yes. TLS1.3 makes the certificate less visible to onlookers, but still a MITM
would be able to collect it.

We spent some time considering if we could turn the connection around so that
the Registrar spoke first, giving the Pledge the opportunity to decide
whether to provide it's identity or not.
But, how would it decide?

In the ANI case, we are likely doing this over wired links (long-haul fiber
or internal to DC), but in the anticipated TEAP-BRSKI use case or 6tisch
use, this would be WIFI / 802.15.4.

What is needed is a three-party zero-knowledge proof, but how would the
Registrar identify the third party (the MASA)?

You are right to worry, but I don't know what to do about this.

    > Section 2.5.1

    > The pledge is the device that is attempting to join.  Until the
    > pledge completes the enrollment process, it has link-local network
    > connectivity only to the proxy.

    > nit(?): I think there is a subtle difference in  meaning between "only
    > has link-local network connectivity to the proxy" and this text, and I'm
    > not sure which is intended.

I'm confused.

    > Section 2.5.3

    > This may just be my personal preference (so feel free to ignore), but
    > talking about a "trust store used to authenticate the MASA" and "trust
    > store used to authenticate the pledge" would feel more readable than
    > "trust anchor database for authenticating the [thing] TLS connection
    > [thing] certificate".

    > It may be worth some comment about how this requirement for out-of-band
    > distribution of implicit trust anchors is something that BRSKI is
    > designed to avoid, but that distributing to just the registrar is a much
    > more manageable task than distributing them to all devices/pledges.

I think that the words "Implicit Trust Anchor" are supposed to invoke
RFC7030's section 3.6.2.   *** MAX ***
I'm okay with your text too.

    > Section 2.5.5

    > The Public Key Infrastructure (PKI) administers certificates for the
    > domain of concerns, providing the trust anchor(s) for it and allowing

    > nit: "domain of concern" singular

fixed.

    > The voucher provides a method for the distribution of a single PKI
    > trust anchor (as the "pinned-domain-cert").  A distribution of the

    > Earlier we talked about the "pinned-domain-cert leaf" in  the domainID
    > definition.  Was that supposed to be "leaf"  in the YANG sense and not
    > in the PKIX "leaf certificate"/"end-entity certificate" sense?

Yes.
I'll change "leaf" above to "attribute"

    > The expectations of the PKI are unchanged from EST [[RFC7030]].  This
    > Which parts of RFC 7030 talk about its expectations of the PKI?

The fact that the public key infrastructure can enroll new
end-entity certificates?   I agree that 7030 doesn't really set out
the expectations in one place.
*** MAX ***

    > Section 2.6.1

    > Many devices when bootstrapping do not have knowledge of the current
    > time.  Mechanisms such as Network Time Protocols cannot be secured
    > until bootstrapping is complete.  Therefore bootstrapping is defined
    > in a method that does not require knowledge of the current time.  A

    > nit: I'd suggest maybe "framework", "scenario", or "environment" rather
    > than "method".

done.

    > Section 2.6.2

    > [RFC5280] explains that long lived pledge certificates "SHOULD be
    > assigned the GeneralizedTime value of 99991231235959Z".  Registrars

    > This misses the important "for the notAfter field" part.

    > Why is 3 years the relevant cutoff here?

That's a good question. *** MAX ***

    > Section 2.7

    > There exist operationally open network wherein devices gain

    > nit: "networks"  plural

fixed.

    > unauthenticated access to the internet at large.  In these use cases
    > the management domain for the device needs to be discovered within
    > the larger internet.  These are less likely within the anima scope
    > but may be more important in the future.

    > nit: less likely than what?

changed to:
          The case where a device can boot and get access to
          larger Internet are less likely within the ANIMA ACP scope but may
          be more important in the future.
          In the ANIMA ACP scope, new
          devices will be quarantined behind a Join Proxy.

    > In order to support these scenarios, the pledge MAY contact a well
    > known URI of a cloud registrar if a local registrar cannot be
    > discovered or if the pledge's target use cases do not include a local
    > registrar.

    ben> I don't see the connection between "configure itself to become the
    ben> local registrar" and "contact a well-known URI of a cloud registrar".

In a completely Greenfield situation, where there is no local infrastructure
at all, given an appropriately magic "Intent" (remember where this WG
started...), then a cloud registrar could inform a device that it is
to become the Registrar.  How this would work depends upon the details
of the magic unicorn Intent (see failed SUPA WG).

    > If the pledge uses a well known URI for contacting a cloud registrar
    > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
    > authenticate service as described in [RFC6125].  This is consistent

    ben> Would this be more likely to be installed by the manufacturer or
    ben> device owner?

Manufacturer, as it's implicit.  That's how EST works today.

    > nit: "service" needs an article.

add "that"

    > Section 2.8

    > approach if they ensure a single MASA URL works for all pledge's
    > associated with each trust anchor.

    > nit: "pledges" non-possessive

Seems pledges should be plural to be.
Changed to:
        This is useful for Registrars which are servicing pledges on directly
        connected networks.or plural

    > Section 3

    > A pledge forms the "pledge voucher-request" and submits it to the
    > registrar.

already fixed.

    > The "proximity-registrar-cert" leaf is used in the pledge voucher-
    > requests.  This provides a method for the pledge to assert the
    > registrar's proximity.

    > "proximity" in what sense?  How much verification/confidence needs to be
    > done?  (Also, I would have expected the assertion to go the other way;
    > that the registrar asserts the pledge's proximity -- how does the pledge
    > have a way to know that the registrar is nearby when the proxy is
    > transparent?)

There is a TLS connection between them.  Yes, it could go anywhere.
The proxy was link-local, and the proxy pointed the connection at the
Registrar.  I guess it would be useful if the proxy was stateful, and
contributed another cryptographic layer for non-ACP cases.

In the ACP case, the Registrar knows it can trust the proxy because it's on
the ACP, and is connecting from an ULA address that is part of the ACP.

Yes, the Registrar could be anywhere, but the proxy makes it appear
to be on the local link.

I'm not sure what else I can add to the text.

    > Section 3.3

    > Example (1)  The following example illustrates a pledge voucher-
    > request.  The assertion leaf is indicated as 'proximity'
    > and the registrar's TLS server certificate is included
    > in the 'proximity-registrar-cert' leaf.  See
    > Section 5.2.

    > {
    > "ietf-voucher-request:voucher": {
    > "nonce": "62a2e7693d82fcda2624de58fb6722e5",
    > "created-on": "2017-01-01T00:00:00.000Z",
    > "proximity-registrar-cert": "base64encodedvalue=="
    > }
    > }

    > I do not see an 'assertion' leaf populated.

added.

    > Example (2)  The following example illustrates a registrar voucher-
    > request.  The 'prior-signed-voucher-request' leaf is
    > populated with the pledge's voucher-request (such as the
    > prior example).  The pledge's voucher-request is a
    > binary object.  In the JSON encoding used here it must

    > Why is it a binary object?  We just saw a previous example with a JSON
    > (non-binary) encoding.  (Hint: CMS-signed,but we didn't say that.)

okay, I'll say that.

    > There is (again) no assertion, and the created-on does not match
    > exactly.

added.

    > Section 3.4

    > The RFC 8174 version of the BCP 14 boilerplate could be used in the
    > module, too.
    > Also, is the 2017 copyright still correct, especially given that it is a
    > 2018-02-14 revision?

already fixed.
fixing date.

    > For example, a pledge might sign a voucher request
    > with a proximity-registrar-cert, and the registrar
    > then includes it in the prior-signed-voucher-request field.

    > nit: maybe "includes it" could be disambiguated (perhaps s/in/as/)?

okay.

    > This is a simple mechanism for a chain of trusted
    > parties to change a voucher request, while
    > maintaining the prior signature information.

    > "chain" seems to admit the possibility of more than one
    > modification/resigning event, but the architecture as described seems to
    > only have the registrar doing this.

Yes. prior-signed-voucher-request could be used in new ways.

    > registrar agree on proximity assertions. The MASA SHOULD
    > remove all prior-signed-voucher-request information when
    > signing a voucher for imprinting so as to minimize the
    > final voucher size.";

    > (side note?) This removal would open up some minor exotic attacks in
    > cases where a pledge reuses an existing nonce (potentially from a
    > different device), but is probably an okay tradeoff to make.

agreed.

    > The first certificate in the Registrar TLS server
    > certificate_list sequence  (see [RFC5246]) presented by
    > the Registrar to the Pledge. This MUST be populated in a
    > Pledge's voucher request if a proximity assertion is
    > requested.";

    > 5246 is replaced by 8446.

okay.  Annoying to have references in the YANG module itself.

    > It might be simplest to just say the "end-entity TLS certificate", at
    > least for TLS practitioners.  (Maybe nof for a different audience,
    > though.)
    > How do I know that a proximity assertion is requested?

That is, How does the pledge knows it wants one?
Because it's been programmed that way.
I have removed "if", and replaced it with "when".
I have added the words "end-entity TLS certificate" to hammer the point.

    > Section 4

    > The role of the proxy is to facilitate communications.  The proxy
    > forwards packets between the pledge and a registrar that has been
    > provisioned to the proxy via GRASP discovery.

    > [same DULL question as above]

It's not DULL, because this is the Proxy speaking within the ACP.
I will write "full GRASP".

    > The proxy does not terminate the TLS handshake: it passes streams of
    > bytes onward without examination.  A proxy MUST NOT assume any
    > specific TLS version.

    > Passing bytes without examination is by definition not assuming any
    > version of TLS.  So while I  think it would make the most  sense to just
    > remove that sentence, if it's going to say it  might be worth also
    > noting the TLS invariants discussed in
    > https://tools.ietf.org/html/rfc8446#section-9.3 .

added reference.

    > Section 4.1

    > through a proxy.  The proxy is transparent to the pledge.  The
    > communication between the pledge is over IPv6 Link-Local addresses.

    > nit: between the pledge and what?

Join Proxy added.

    > M_FLOOD.  The active methods SHOULD exponentially back-off to a
    > maximum of one hour to avoid overloading the network with discovery
    > attempts.  Detection of change of physical link status (ethernet
    > carrier for instance) SHOULD reset the exponential back off.

    > Mathematically, "exponential" requires to specify the base of the
    > exponent (or just say "by doubling").  (Also later in the section.)

Well, of course the base should be "e" :-)
I'll write doubling.

    > Once all discovered services are attempted (assuming that none
    > succeeded) the device MUST return to listening for GRASP M_FLOOD.  It
    > SHOULD periodically retry the manufacturer specific mechanisms.  The
    > pledge MAY prioritize selection order as appropriate for the
    > anticipated environment.

    > nit: "manufacturer-specific" takes a hyphen
    > not-nit: what are "the manufacturer-specific mechanisms"?  (I don't
    > remember such discussion yet.)

1) Appendix A and Appendix B.
2) a bunch of manufacturers have proprietary equivalent of BRSKI.
   I think that this includes both Cisco and Juniper.

    > Section 4.1.1

    > Is Figure 6b supposed to be using JSON diagnostic notation for CBOR or
    > some other notation?
    > Also, I'm not sure that picking an arbitrary (representative) session-id
    > value, LL address, and port is helpful when describing the formatting of
    > the message.  Maybe some different introductory text would change
    > things.

I have placed the example after the CDDL.

    > Section 4.3

    > If we're only defining an EST-TLS objective, how will proxies know that
    > the registrar supports BRSKI?

    > It's a little weird to put the reference for GRASP but not ACP.  Either
    > none or both would feel more natural (given that we've seen both already
    > a couple times).

The name is "AN_join_registrar", which implies BRSKI.
The objective-value of "EST-TLS" means EST. (vs CMP or some other enrollment
mechanism that people have asked for).  There could be many announcements
From different things.
This announcement and the Join Proxy described here only applies to ACP.

Added:
      <t>
        This section applies is normative for uses with an ANIMA ACP.
        The use of GRASP mechanism part of the ACP.
        Other users of BRSKI will need to define an equivalent proxy
        mechanism, and an equivalent mechanism to configure the proxy.
      </t>

the beginning of section 4.

    > Section 5

    > MASA URI is "https://" iauthority "/.well-known/est".

    > nit: "The MASA URI".
    > Is this always the case, with no opportunity for modification, even as
    > included in an IDevID certificate extension?

Either just the iauthority (now "authority") is present in the IDevID, or the
entire URL (with ports numbers and paths) is present.  I think that is what
you want.

    > BRSKI uses JSON [RFC7159] for all new operations defined here, and

    > RFC 7159 is obsoleted by RFC 8259.

already fixed.

    > While EST section 3.2 does not insist upon use of HTTP 1.1 persistent
    > connections, BRSKI-EST connections SHOULD use persistent connections.
    > The intention of this guidance is to ensure the provisional TLS state
    > occurs only once, and that the subsequent resolution of the provision
    > state is not subject to a MITM attack during a critical phase.

    > I think we probably want a requirement that if persistent connections
    > are not used (and what about HTTP/2 or HTTP/3 ones?), the pledge MUST
    > check that the exact same certificate is used to authenticate the
    > registrar for all transactions.  If the signature in the handshake is
    > valid but you can only chain the certificate up to your trust anchor
    > once you finish imprinting, you still know that the entire session's
    > data has been talking to the now-authenticated party (as opposed to the
    > TLS case where you try to add a new certificate mid-connection, where
    > that boundary is unclear), but things are much easier to reason about if
    > you are sure that each EST transaction is talking to the same peer.

We had a conversation two years ago about what we might need to say about
HTTP/2, and aside from being unable to handle QUIC (due to proxy), we don't
see any issue.

I have added:
        <t>
          If non-persistent connections are used, then both the pledge and
          the registrar MUST remember the certificates seen, and also sent
          for the first connection.  They MUST check each subsequent
          connections for the same certificates, and each end MUST use
          the same certificates as well.  This places a difficult restriction
          on rolling certificates on the Registrar.
        </t>

But, that's why we have SHOULD, and the SHOULD (vs MUST) part was really to
allow for some fancy HTTP/3 we know nothing about :-)

    > o  In the language of [RFC6125] this provides for a SERIALNUM-ID
    > category of identifier that can be included in a certificate and
    > therefore that can also be used for matching purposes.  The
    > SERIALNUM-ID whitelist is collated according to manufacturer trust
    > anchor since serial numbers are not globally unique.

    > RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in
    > the model of RFC 6125" or "provides a new SERIAL-ID category" or
    > similar.

I have an open request to *** MAX *** to clarify this part.

    > o  The registrar performs log verifications in addition to local
    > authorization checks before accepting optional pledge device
    > enrollment requests.

    > Maybe give us a section reference to what the "log validations" are?

We decided that we did not have enough experience to write normative language
here.  (It's not an Internet Standard)

    > Section 5.1

    > Establishment of the BRSKI-EST TLS connection is as specified in EST
    > [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates"
    > [RFC7030] wherein the client is authenticated with the IDevID
    > certificate, and the EST server (the registrar) is provisionally
    > authenticated with an unverified server certificate.

    > I'd consider noting that the signature (or other operation) made by the
    > certificate must be validated, and that the received certificate and
    > chain must be retained for later validation.

Added:
            <t>
              The signatures in the certificate MUST be validated even if a
              signing key can not (yet) be validated.  The certificate (or
              chain) MUST be retained for later validation.
            </t>
            <t>
              A self-signed
              certificate for the Registrar is acceptable as the voucher
              will validate it.
            </t>

    > The pledge maintains a security paranoia concerning the provisional
    > state, and all data received, until a voucher is received and
    > verified as specified in Section 5.6.1

    > Since section 5.6.1 just talks about the voucher verification process, I
    > think we need to say more about what "security paranoia" entails:
    > acknowledging that all data transmitted is sent to an unauthenticated
    > peer, with corresponding privacy considerations, and that all received
    > data is not authenticated by the TLS connection and must be
    > self-authenticating or otherwise considered untrusted.

            <t>
              The pledge code needs to be written with the assumption that
              all data is being transmitted at this point to an
              unauthenticated peer, and that received data, while inside a
              TLS connection, MUST be considered untrusted.  This
              particularly applies to HTTP headers and CMS structures that
              make up the voucher.
            </t>

    > A pledge that can not maintain as many connections as there are
    > eligible proxies.  If no connection is making process after 5 seconds

    > nit: that's not a complete sentence.

already fixed to:
            <t>
              A pledge that can not maintain as many connections as there are
              eligible proxies will need to rotate among the various choices,
              terminating connections that do not appear to be making
              progress.

stopping here for today.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Aug 2019 17:55:41 -0500

> I did split up the last sentence.

This was a side note, so for my own edification more than the good of the
document...

> So I'm not sure what further to do here.

...and this helps; thank you!

> since X.509v3, so I don't think that X.509v3 is an appropriate noun

I think this discussion is continuing in the other thread, right?

> Do you think we can demand that the extension be present in IDevID?

I'm doubtful that we have enough leverage to make that stick.

> it didn't specify a way to identify keys with SHA-2, although the mechanism

So, if all we're going for is "consistent with the 5280 SKI", then "the
SHA-256 hash of the BIT STRING of the [...] certificate" is still going to
meet that bar.

I guess the pithy version of my stance here is that "from a standards
point of view it's easy to move to SHA-2, and we should only think about
sticking with SHA-1 if there's an implemnetation or deployment reason to do
so".

> so, I can change the word to "can" rather than "is"

(and fix up the grammar, but) sure

> I don't think it's mentioned just in passing.

It looks like the main coverage here is:

   o  the identity of the device being enrolled (down to the serial-
      number!).

and the discussion in the last three paragraphs or so.
I do appreciate the importance of distinguishing between the high-end
router and the human users (and we will have a long hard think about it
again when BRSKI profiles for IoT use come through, I'm sure), so thank you
for that.  But I'm not sure that we clearly draw the connection to "the
manufacturer knows the identity of the device being enrolled" to "and can
guess where it is, and definitely knows who the owner is, and can
potentially follow that over time if the device has to reenroll".  Now, for
the high-end router case there is literally nothing new here -- the vendor
is assumed to already be doing inventory tracking of which customers have
which routers!  But I think it's important to make the connection from
"knows identity" to "tracking", since this topic will come up for any use
of BRSKI in other situations.

> provided by the Pledge; it has to be linked to SOME manufacturer. Some

Well, it has to be linked to some entity that signed the IDevID.  That may
or may not be a manufacturer, but the Registrar does have the capability to
look at what signed the IDevID and apply a whitelist of known, verified,
manufacturers.

> to use until after there is communication with the MASA)

Sure, that is probably a feature at least in some cases.
But can we assume that a given pledge has a single distinguished MASA?
The pledge gives the registrar a thing that says "go here for my MASA", and
the registrar can do a fair bit of validation on that, but there's still
potentially some control in the pledge's hands about where the registrar
goes to, and lots of room for attack by hostile pledges if the registrar is
buggy.

It's not like there's a single authoritative (global) database of (device,
MASA) pairs that we can query and have unconditional trust is giving the
right result (and validating what device we're looking up, even).  Things
are fragmented, and at the protocol level, we can't be confident that we
wouldn't get a different (valid!) answer if we asked somewhere else, or
asked a slightly different question.  (And, given the track record of Web
PKI CAs, I expect some baseline level of bogus IDevIDs to be out there.)

>   https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc703626012d62c0b3138d851b61a2f54

Maybe, "Configuration or distribution of these trust anchor databases is
out-of-scope of this specification.  Note that the trust anchors
in/excluded from the database will affect which manufacturers' devices are
acceptable to the registrar as pledges, and can also be used to limit the
set of MASAs that are trusted for enrollment."?

> I don't seem to be able to get the 2018 edition.

I think we could probably reword this to just acknowledge that [IDevID]
acknowledges that adding restrictions in the certificate can limit
applicability, and since these are long-lived, usually you don't want to
throw random extra restrictions into them.

> I don't know why this advice against EKU is gone from the 2018 edition.

"Which part is the advice against EKU?"

> From when voucher-requests could be unsigned.

I don't actually have a big complaint, here (and am definitely not asking
to change the wire bits!).  Perhaps we could go easy on "unique" or maybe
just acknowledge that there's supposed to be a 1:1 map between serial
number and IDevID.  (Or not, of course.)

> and mDNS possible here.  Do you have suggestions on making it clearer.

Hmm, maybe give each one a unique symbol (+*&$#?) and put that in the
middle of the relevant arrows as well as in the text?

> But, how would it decide?

Indeed.

> You are right to worry, but I don't know what to do about this.

I don't, either.  Well, I do: "document it and move on", but that still
leaves a bad taste in my mouth.

>     > not sure which is intended.

The current text asserts that it has link-local connectivity, and further
that the extent of this connectivity is limited to the proxy.  My
alternative asserts that it can only talk to the proxy over this link-local
connectivity, but leaves open the possibility of other avenues of
communication (e.g., a WWAN card).

> I'm okay with your text too.

I have no way to tell what is just my personal preference and what is
objectively better, so feel free to ignore.

>     > This misses the important "for the notAfter field" part.

(The above and below were separate comments; not sure if that came
through.)

> of the magic unicorn Intent (see failed SUPA WG).

Ah.  So the cloud registrar is an extra-featureful registrar that can do
more than just register things.  I get it now, but am not sure how to best
word it.

> Manufacturer, as it's implicit.  That's how EST works today.

So you think "implicit" is enough and adding something like "burned-in" or
"manufacturer-assigned" is overkill?

> I'm not sure what else I can add to the text.

"There is a TLS connection between a and b" says almost nothing without
some additional context -- there are millions of machines I can make a TLS
connection to from here.  I assume that the unstated context here is that
the pledge is expected to be in a limited-connectivity environment, so the
fact that the network allowed the connection through to the registrar
conveys meaning.  But I don't remember anything in this document that
actually validates that the pledge really is in a limited network
environment.  Could some rogue node ("attacker") be trying to talk to a
proxy or registrar directly, from somewhere else in the network?  How would
we tell?

> mechanism that people have asked for).  There could be many announcements

Ah, I was misparsing the diagnostic notation, sorry.

> the beginning of section 4.

and thank you for the clarification!

> allow for some fancy HTTP/3 we know nothing about :-)

:)

Do we still want to say "HTTP 1.1 persistent connections" vs. "HTTP
persistent connections", though?

> here.  (It's not an Internet Standard)

It doesn't have to be normative, but some discussion of things that might
come into consideration during that process could still be useful.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Aug 2019 22:27:59 -0400

Based upon the comment that the author list on the YANG module, and
the author list on the document did not match, the authors had
a bit of a think on this, and decided that we would remove
Steinthor Bjarnason and add Toerless Eckert.
** Everyone was consulted beforehand **

Steinthor Bjarnason originated many of the ideas in the document four plus
years ago, but has not been able to contribute to it for a number of
years.  We prominently acknowledge his contribution.

Toerless Eckert made many editorial passes over the past two years
and turned himself from document shepherd and co-chair into a regular
contributor.

As he was also the document shepherd, we had a conversation with
our AD about the appropriateness of this change, and got approval.

The WG, of course, may have other opinions, as it is the WG's document,
and people should not feel shy this.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Aug 2019 00:06:07 -0400

https://tinyurl.com/yylruorn contains an updated diff against -24.

Benjamin Kaduk via Datatracker <[email-masked]> wrote:
    > Section 5.2

    > application/voucher-cms+json  The request is a "YANG-defined JSON
    > document that has been signed using a CMS structure" as described
    > in Section 3 using the JSON encoding described in [RFC7951].  This

    > Section 3 does not describe any "sign[ing] using a CMS structure"
    > operation.

Yes, I see, the sentence structure is wrong.  I have changed it:

-   application/voucher-cms+json  The request is a "YANG-defined JSON
-      document that has been signed using a CMS structure" as described
-      in Section 3 using the JSON encoding described in [RFC7951].  This
-      voucher media type is defined in [RFC8366] and is also used for
-      the pledge voucher-request.  The pledge SHOULD sign the request
-      using the Section 2.3 credential.

+   application/voucher-cms+json  [RFC8366] defines a "YANG-defined JSON
+      document that has been signed using a CMS structure", and the
+      voucher-request described in Section 3 is created in the same way.
+      The media type is the same as defined in [RFC8366].  and is also
+      used for the pledge voucher-request.  The pledge MUST sign the
+      request using the Section 2.3 credential.

    > To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other
    > credential) to sign?

It was SHOULD, because we supported unsigned voucher requests, but we removed
that option.  It is now MUST.

    > constrained voucher formats are expected in the future.  Registrar's
    > and MASA's are expected to be flexible in what they accept.

    > nits: no apostrophes for plurals.

done.

    > proximity-registrar-cert:  In a pledge voucher-request this is the
    > first certificate in the TLS server 'certificate_list' sequence
    > (see [RFC5246]) presented by the registrar to the pledge.  This
    > MUST be populated in a pledge voucher-request if the "proximity"
    > assertion is populated.

    > [same comment as above about "end-entity certificate"]

done.

    > The registrar validates the client identity as described in EST
    > [RFC7030] section 3.3.2.  The registrar confirms that the 'proximity'
    > assertion and associated 'proximity-registrar-cert' are correct.

    > what 'proximity' assertion?
    > Does verifying proximity-registrar-cert just mean checking that it's the
    > same leaf certificate that the registrar presented?  What happens if the
    > validation fails?

Yes, it means confirming that the pinned certificate is one's own.
If it fails, then there is a MITM, and the connection should be closed.
{I will use "MITM" until someone tells if me we are using a different term}

I've split that paragraph up, as there are two thoughts, one is about the
ClientCertificate, and the other is about the pinned certificate.

    The registrar validates the client identity as described in EST
-   [RFC7030] section 3.3.2.  The registrar confirms that the 'proximity'
-   assertion and associated 'proximity-registrar-cert' are correct.
+   [RFC7030] section 3.3.2.
+
+   The registrar confirms that the assertion is 'proximity' and that
+   pinned 'proximity-registrar-cert' is the Registrar's certificate.  If
+   this validation fails, then there a On-Path Attacker (MITM), and the
+   connection MUST be closed after the returning an HTTP 401 error code.

    > Section 5.3

    doc> A Registrar accepts or declines a request to join the domain, based
    doc> on the authenticated identity presented.  Automated acceptance
    doc> criteria include:

    > I suggest "for different networks, examples of automated acceptance
    > criteria may include".

    doc> If these validations fail the registrar SHOULD respond with an
    doc> appropriate HTTP error code.

    > Similarly, "If validation fails".

done.

    > Section 5.4

    doc> The BRSKI-MASA TLS connection is a 'normal' TLS connection
    doc> appropriate for HTTPS REST interfaces.  The registrar initiates the
    doc> connection and uses the MASA URL obtained as described in Section 2.8
    doc> for [RFC6125] authentication of the MASA.

    > I'd consider mentioning  the implicit trust anchor database as well as
    > the MASA URL.

edits for another review changed this to:
   The BRSKI-MASA TLS connection is a 'normal' TLS connection
   appropriate for HTTPS REST interfaces.  The registrar initiates the
   connection and uses the MASA URL obtained as described in
   Section 2.8.  The mechanisms in [RFC6125] SHOULD be used
   authentication of the MASA.  Some vendors will establish explicit (or
   private) trust anchors for validating their MASA; this will typically
   done as part of a sales channel integration.  Registars SHOULD permit
   trust anchors to be pre-configured on a per-vendor basis.

    doc> The MASA and the registrars SHOULD be prepared to support TLS client
    doc> certificate authentication and/or HTTP Basic or Digest authentication
    doc> as described in [RFC7030] for EST clients.  This connection MAY also
    doc> have no client authentication at all (Section 7.4)

    > I don't see discussion of skipping client authentication in Section 7.4.
    > It would be great to have some, there!

It's buried in point 2.
I moved text from 7.4 into a new 5.4.1, I created 7.4.1/7.4.2 so that it
could be forward referenced.  Diff too long here, see link above.

    doc> The authentication of the BRSKI-MASA connection does not affect the
    doc> voucher-request process, as voucher-requests are already signed by
    doc> the registrar.  Instead, this authentication provides access control
    doc> to the audit log.

    > I don't understand what "access control to the audit log" means.  Is the
    > idea that the TLS client identity in the BSRKI-MASA connection is only
    > used when processing requests to the requestauditlog endpoint and that
    > some clients might be denied access?

The audit log reveals who owns what.  Revealing it to strangers would be a problem.
So in order to get access to the audit log for device FOO, one presents a
voucher-request for FOO.  Since the request contains a serial-number and a
mapping to an owner, we use that as an access key to get the audit-log.
The identity that the MASA sees in the HTTPS request (ClientCertificate
preferred), says who is asking.

What can I fix here?

    > Section 5.5

    doc> created-on:  Registrars are RECOMMENDED to populate this field.  This
    doc> provides additional information to the MASA.

    > Earlier we said that this field would be propagated from the pledge
    > voucher-request; we should probably say something like "populate this
    > field; if it was present in the pledge voucher-request it is copied
    > unchanged to the registrar voucher-request; otherwise the current time
    > is used".

That create-on is the time on the Registrar, not on the pledge. It currently
says:

   The registrar populates the voucher-request fields as follows:

   created-on:  The Registrars SHOULD populate this field with the
      current date and time when the Registrar formed this voucher
      request.  This field provides additional information to the MASA.

    > nonce:  This is the value from the pledge voucher-request.  The
    > registrar voucher-request MAY omit the nonce as per Section 3.1)

    > I'd suggest "value from the pledge voucher-request, if present" and
    > changing the second sentence to refer to the pledge voucher-request.

I've written:

   nonce:  This value, if present, is copied from the pledge voucher-
      request.  The registrar voucher-request MAY omit the nonce as per
      Section 3.1.

It's up to the Registrar whether to include the nonce.
A registrar may issue a voucher-request on it's own, if it is trying to get
an offline voucher.

    > idevid-issuer:  The idevid-issuer value from the pledge certificate
    > is included to ensure a statistically unique identity.

    > There is no "idevid-issuer" field in the pledge certificate; I assume
    > this is supposed to be the Issuer Name of the IDevID certificate.

Changed to:
   idevid-issuer:  The Issuer value from the value from the pledge
      IDevID certificate is included to ensure a uniqueness of the
      serial-number.  In the case of nonceless (offline) voucher-
      request, then an appropriate value needs to be configured from the
      same out-of-band source as the serial-number.

    > prior-signed-voucher-request:  The signed pledge voucher-request
    > SHOULD be included in the registrar voucher-request.  (NOTE: what
    > is included is the complete pledge voucher-request, inclusive of
    > the 'assertion', 'proximity-registrar-cert', etc wrapped by the
    > pledge's original signature).  If a signed voucher-request was not
    > recieved from the pledge then this leaf is omitted from the
    > registrar voucher request.

    > This is a good example of text that implies the signed voucher is
    > binary.  (And as such would be a good place to talk about the base64
    > encoding.)

okay, done.

    > All other fields MAY be omitted in the registrar voucher-request.

    > Should the proximity-registrar-cert field *not* be present?

Correct, it's from the pledge->registrar.

    > Section 5.5.2

    doc> The MASA MUST verify that the registrar voucher-request is signed by
    doc> a registrar.  This is confirmed by verifying that the id-kp-cmcRA
    doc> extended key usage extension field (as detailed in EST RFC7030
    doc> section 3.6.1) exists in the certificate of the entity that signed
    doc> the registrar voucher-request.  This verification is only a
    doc> consistency check that the unauthenticated domain CA intended the
    doc> voucher-request signer to be a registrar.  Performing this check
    doc> provides value to the domain PKI by assuring the domain administrator
    doc> that the MASA service will only respect claims from authorized
    doc> Registration Authorities of the domain.

    > If the MASA has no prior knowledge of the domain (certificate), this is
    > susceptible to anyone spinning up something that claims to be a domain
    > CA and issuing registrar certs with that extension.  We need to document
    > somewhere what other part of the system prevents that from causing an
    > unauthorized voucher to be used.  (Perhaps preventing one from being
    > issued is not feasible, but acceptable if the pledge will not accept
    > it, though there remains risk of DoS on the MASA.)

The ability for someone to spin up a domain is part one of the ways that the
MASA MAY operate in the absense of supply chain integration.  The audit-log
is the defense against this.  If the MASA does not want to do business with
such entities, then it just doesn't.

    > Section 5.5.3

    doc> If a nonceless voucher-request is submitted the MASA MUST
    doc> authenticate the registrar as described in either EST [RFC7030]
    doc> section 3.2, section 3.3, or by validating the registrar's

    > Subsubsection references might be more helpful.

done.

    doc> In the nonced case, validation of the registrar MAY be omitted if the
    doc> device policy is to accept audit-only vouchers.

    > I don't see any (SHOULD?) guidance about validating the registrar in the
    > nonced case when other policy is used.  Even the previous section does
    > not really say much to indicate there is value in authenticating the
    > signature on the voucher request.

The signature on the pledge voucher-request is always validated.
The signature on the registrar voucher-request is also always validated.
What's optional is validating the TLS ClientCertificate/HTTP of the
Registrar.

I've added a few words to say this.

    > Section 5.5.4

    doc> authentication or voucher-request signature validation.  Similarly,
    doc> as noted in Section 5.5.2, the MASA performs normal PKIX revocation
    doc> checking during signature consistency checks (a signature by a
    doc> registrar certificate that has been revoked is an inconsistency).

    > I think this needs to be noted more clearly in Section 5.5.2.

I'll ask *** MAX *** to help here.

    > Section 5.5.5

    doc> The MASA MAY verify that the registrar voucher-request includes the
    doc> 'prior-signed-voucher-request' field.  If so the prior-signed-
    doc> voucher-request MUST include a 'proximity-registrar-cert' that is
    doc> consistent with the certificate used to sign the registrar voucher-
    doc> request.  Additionally the voucher-request serial-number leaf MUST

    > This seems kind of tautological ("if the MASA is checking X, X MUST have
    > happened").  Also, what does "consistent with"  mean?

If the MASA is configured to issue nonceless vouchers for this device, then
no prior-signed-voucher-request field is needed.  If it's there, then it must
be valid.

    doc> match the pledge serial-number that the MASA extracts from the
    doc> signing certificate of the prior-signed-voucher-request.  The MASA is
    doc> aware of which pledges support signing of their voucher requests and
    doc> can use this information to confirm proximity of the pledge with the
    doc> registrar, thus ensuring that the BRSKI-EST TLS connection has no
    doc> man-in-the-middle.

    > To be clear, this MITM detection is only for the case of pledges that
    > sign their voucher requests, right?  And it seems to only hold if
    > pledges that support signing actually do sign, every time.

Yes, and also we have removed unsigned, so this is another place we missed
a conditional on that.  I want to note that the manufacturer knows, by
construction, what the behaviour of the pledge is.
So I've removed the last sentence completely

    > Section 5.5.6

    doc> The registrar's certificate chain is extracted from the signature
    doc> method.  The chain includes the domain CA certificate as specified in
    doc> Section 5.5.  This certificate is used to populate the "pinned-

    > I don't think Section 5.5 is the right reference for "includes the
    > domain CA certificate" (both here and in 5.5.2).

It's referring to:
   The entire
   registrar certificate chain, up to and including the Domain CA, MUST
   be included in the CMS structure.

I think that 5.5.2 is the right pointer.

    doc> domain-cert" of the voucher being issued.  The domainID (e.g., hash
    doc> of the root public key) is determined from the pinned-domain-cert and
    doc> is used to update the audit log.

    > If the pinning takes the whole cert (per RFC 8366), then what do we need
    > the domainID for?  Just the audit log?  Surely in that case SHA-1 is
    > not a hard requirement...

I've changed the domainID definition such that it uses the
SubjectKeyIdentifier, if present.  That can be any algorithm that the CA
wants to use to identify the Entity certificate.  We need to have a
consistently calculated value if it's not present, and RFC5280 says SHA-1.

   domainID:  The domain IDentity is a unique hash based upon a
      Registrar's certificate.  If the certificate includes the
      SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
      used as the domainID.  If not, then the 160-bit SHA-1 hash as
      described in that section is to be used.  This value needs to be
      calculated by both MASA (to populate the audit log), and by the
      Registrar (to recognize itself).

Does this work?  We are only using SHA-1 (for identification, btw, not
for resistence to pre-image attacks) as a last resort.

I'm looking for a place where I could RECOMMEND that Registrar certificates
have SubjectKeyIdentifier added.  To 5.1, I have added:

            <t>
              <xref target="RFC5280" /> section 4.2.1.2 does not mandate that the
              SubjectKeyIdentifier extension be present in non-CA certificates.
              It is RECOMMENDED that Registrar certificates (even if
              self-signed), always include the SubjectKeyIdentifier to be
              used as a DomainID, and that a hash stronger than SHA-1 be
              used.
            </t>

    > Section 5.5.7

    doc> The MASA MUST use the nonce from the registrar voucher-request for
    doc> the resulting voucher and audit log.  The prior-signed-voucher-
    doc> request nonce is ignored during this operation.

    > I don't understand this requirement.  They could only be different if
    > the MUST from the previous paragraph is ignored.

The Registrar may include no nonce. So I agree it looks weird at this point.
I will change this to:

   The MASA populates the audit-log with the nonce that was verified.
   If a nonceless voucher is issued, then the audit log is to be
   populated with the JSON value "null".

and I noticed that the audit log asked for the string "null", rather than a
JSON null.

    > Section 5.6

    doc> The MASA voucher response to the registrar is forwarded without
    doc> changes to the pledge; therefore this section applies to both the
    doc> MASA and the registrar.  The HTTP signaling described applies to both
    doc> the MASA and registrar responses.  A registrar either caches prior
    doc> MASA responses or dynamically requests a new voucher based on local
    doc> policy (it does not generate or sign a voucher).  [...]

    > Do we need to say how this local caching policy interacts with HTTP
    > cache control headers?

All of the requests are via POST. We are not permitting 201 returns for the
voucher-request (with GET to the Location:), so there can be no opportunity
to cache.

If the Registrar caches a voucher, it would be caching a nonceless one.

    > I got confused by "or dynamically requests a new voucher" the first
    > couple times I read it; I landed on something like "when a voucher
    > request arrives at the registrar, if it has a cached response from the
    > MASA for the corresponding registrar voucher-request, that cached
    > response can be used according to local policy; otherwise the registrar
    > constructs a new registrar voucher-request and sends it to the MASA".

I can use your words.

Perhaps implicit in this is that there are two ways to build a registrar.

The simplest is with a single monolithic application framework, it receives
the voucher-request, and then does a synchronous HTTPS request to the MASA.
(Perhaps doing 100-Continue).
The other way is for the pledge-facing part of the Registrar to put it all
into a database, return 202, and wait for another query.  Asynchronously some
other part sends requests to the MASA and stores the answers back in the
database.  Perhaps the only thing connecting the two parts is some
multi-master database replication... running over
UUCP^WDelay-Tolerant-Networking between planets for all we know.

    > type.  The registrar SHOULD use this response if it determines the
    > pledge is unacceptable due to inventory control, MASA audit logs, or
    > any other reason.

    > What does "unacceptable due to inventory control" mean?

Such as, device is not in the list of devices that were expected, assuming
supply chain integration.

    > A 415 (Unsupported Media Type) response is approriate for a request
    > that has a voucher-request or accept encoding that is not understood.

    > Isn't "Accept-Encoding:" a more typical spelling?

Actually, we meant Accept: .. encoding. I've removed the word encoding,
because I see that it's confusing.
        <t>
          A 415 (Unsupported Media Type) response is appropriate
          for a request that has a voucher-request or Accept: value that is
          not understood.
        </t>

    > vouchers are described in detail in [RFC8366].  For example, the
    > voucher consists of:

    > {
    > "ietf-voucher:voucher": {
    > "assertion": "logging"
    > "pinned-domain-cert": "base64encodedvalue=="
    > "serial-number": "JADA123456789"
    > }
    > }

    > nit: I think "might consist of" is better than "consists of".

already fixed.

    > assertion:  The method used to verify assertion.  See Section 5.5.5.

    > The method used to verify itself?

Changed to:
        The method used to verify the relationship between pledge and registrar

    doc> The pledge MUST be prepared to parse and fail gracefully from a
    doc> voucher response that does not contain a 'pinned-domain-cert' field.

    > What would such a graceful failure look like?  Reverting back to the
    > discovery stage, since without a manufacturer-validated indication of
    > the trust anchor for the domain, the pledge cannot  consider itself to
    > be a part of a domain?

changed to:
        <t>
          The pledge MUST be prepared to parse and fail gracefully from
          a voucher response that does not contain a 'pinned-domain-cert'
          field.  Such a thing indicates a failure to enroll in this domain,
          and the pledge MUST attempt joining with other available Join Proxy.
        </t>
        <t>
          The pledge MUST be prepared to ignore additional fields that it does not recognize.
        </t>

    > Section 5.6.2

    doc> found.  It SHOULD return to the same proxy again after attempting
    doc> with other proxies.  Attempts should be attempted in the exponential

    > But only if those other proxies failed to produce a valid voucher?

yes, inserted "unsucccessful"

    doc> The pledge's PKIX path validation of a registrar certificate's
    doc> validity period information is as described in Section 2.6.1.  Once
    doc> the PKIX path validation is successful the TLS connection is no
    doc> longer provisional.

    > Section 2.6.1 doesn't actually say that the pledge has to check the five
    > listed timestamps in the case that it does have a realtime clock.

Noted, added text to 2.6.1.

    > Section 5.7

    doc> To indicate pledge status regarding the voucher, the pledge MUST post
    doc> a status message.

    > I think we've had other text that implies that providing telemetry is
    > optional; perhaps just "the pledge POSTs a status message"?

The 5.7 Pledge BRSKI Status Telemtry is mandatory.
The 5.9.4 Enrollment Status Telemtry is not, because enrollment is not mandatory.

    doc> The client HTTP POSTs the following to the server at the EST well
    doc> known URI "/voucher_status".  The Status field indicates if the

    > I think it's probably more clear to write out
    > ".well-known/est/voucher_status"; there's not a separate registry of EST
    > well-known URIs.

okay.

    > We don't actually have anything in  this section that declares "this is
    > the structure of the JSON object used as the POST body"; it's only
    > implicitly provided.

I believe that I have reworked this section as a result of other reviews already.

    doc> indicates why.  In the failure case this message may be sent to an
    doc> unauthenticated, potentially malicious registrar and therefore the
    doc> Reason string SHOULD NOT provide information beneficial to an
    doc> attacker.  The operational benefit of this telemetry information is

    > What sort of information might a pledge consider including that would be
    > beneficial to an attacker?

It's hard to say at this point.
We want things in the logs of the Registrar that will help avoid a truck
roll.  IBM (AIX and friends) was historically really good at having really
detailed, but often uninformative three digits codes, yet they told AIX
support people reams of useful info.

    > This still have some privacy considerations, though.

At this point, the attacking registrar has seen the entire IDevID
certificate.  I would think that putting the GPS coordinates of the device in
the telemetry message would be of course, make things even worse.
On the other hand, if a device has a GPS and can not be installed in some
places to due some kind of geofencing...

    > Section 5.8

    doc> is posted to the /requestauditlog URI instead.  The "idevid-issuer"
    doc> and "serial-number" informs the MASA which log is requested so the
    doc> appropriate log can be prepared for the response.  Using the same

    > Is the implicit point that the other fields are ignored?

Yes.

    doc> A registrar MAY request logs at future times.  If the registrar
    doc> generates a new request then the MASA is forced to perform the
    doc> additional cryptographic operations to verify the new request.

    > Is this statement just supposed to be further justification for using
    > the original voucher-request as the POST body, or describing new
    > behavior?

Further justification.  The MASA can do a memcmp()/SELECT on a history of raw
voucher requests.  {that's what my code does}

    doc> A MASA that receives a request for a device that does not exist, or
    doc> for which the requesting owner was never an owner returns an HTTP 404
    doc> ("Not found") code.

    > What is a "requesting owner"?  I thought devices were owned by the
    > domain, not the specific registrar.

So, if Registrar A has stored a valid pledge-request (or perhaps a falsy
constructed one) for a pledge that has joined another network (B), then
registrar A can not get a history of the pledge if it was never an owner.

If the pledge was once owned by Registrar A (but sold), then there is a hole
that would permit Registrar A to ask for history.  But this is legitimate,
because perhaps it wasn't actually sold, but in fact stolen, and when
they can't get the device to respond, the operator could ask if the device
has become owned by another Registrar.

This interface will likely get future work: some kind of zero-knowledge proof
mechanism would be interesting, but we don't know what exactly are the
requirements yet.

    doc> In order to avoid enumeration of device audit logs, MASA that return
    doc> URLs SHOULD take care to make the returned URL unguessable.  For
    doc> instance, rather than returning URLs containing a database number
    doc> such as https://example.com/auditlog/1234 or the EUI of the device
    doc> such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD
    doc> return a randomly generated value (a "slug" in web parlance).  The
    doc> value is used to find the relevant database entry.

    > https://www.w3.org/TR/capability-urls/ may also be a useful reference.

thanks, added.

That's all for today.

Will the Joker Get Away?  Will the document editor switch to Markdown?
Does the YIN/YANG circle converge ever? Can it be rendered in SVG?
Stay tuned for tomorrow's exciting episode.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Aug 2019 15:05:44 -0400

Benjamin Kaduk via Datatracker <[email-masked]> wrote:
    > Section 5.8.1

    doc>    A log data file is returned consisting of all log entries associated
    doc> with the the device selected by the IDevID presented in the request.
    doc> The audit log may be truncated of old or repeated values as explained
    doc> below.  The returned data is in JSON format ([RFC7951]), and the
    doc> Content-Type SHOULD be "application/json".  For example:

    > If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data".

Typo, it should be 7159.

    doc>    This document specifies a simple log format as provided by the MASA
    doc> service to the registrar.  This format could be improved by distributed
    doc> consensus technologies that integrate vouchers with technologies such
    doc> as block-chain or hash trees or optimized logging approaches.  Doing so
    doc> is out of the scope of this document but is an anticipated improvement
    doc> for future work.  As such, the registrar client SHOULD anticipate new
    doc> kinds of responses, and SHOULD provide operator controls to indicate
    doc> how to process unknown responses.

    > This would be a great place to talk about the "version" field that's
    > otherwise ignored.

As in, what should occur if the "version" is not 1?
How about:

          <t>
            A registrar that sees a version value greater than 1 indicates
            an audit log format that has been enhanced with additional
            information.   No information will be removed in future
            versions; should an incompatible change be desired in the future,
            then a new HTTP end point will be used.
          </t>

    doc>    anticipated improvement for future work.  As such, the registrar
    doc> client SHOULD anticipate new kinds of responses, and SHOULD provide
    doc> operator controls to indicate how to process unknown responses.

    > Is "registrar client" intended to be both words or just one?

Probably not, removed.

    doc>    A registrar SHOULD use the log information to make an informed
    doc> decision regarding the continued bootstrapping of the pledge.  The

    > I may be confused, but I thought the registrar was asking for the log
    > after the voucher had already been issued.  Are these check supposed to
    > keep the registrar from forwarding the voucher to the pledge, or just
    > as a check for future renewal operations?

The voucher can be returned to the Pledge immediately, as there is never
any issue about whether the Pledge should join.  The MASA has already made
that decision.

The Registrar could avoid passing the voucher on until after the audit log
checks are done, or could do that concurrently.  What matters is that the
audit log checks are done prior to the Registrar accepting an enroll
request.    This is down in (what is now) Figure 4.

The Registrar may do additional checks of the audit log at later times,
but I don't think we have any good advice on this yet.

    doc>    A relatively simple policy is to white list known (internal or
    doc> external) domainIDs and to require all vouchers to have a nonce and/ or
    doc> require that all nonceless vouchers be from a subset (e.g. only
    doc> internal) domainIDs.  A simple action is to revoke any locally issued

    > nit: missing "of"

I don't know where the "of" that is missing goes.

While investigating, I broke the big sentence up, and discovered that the
5209 reference was not coded as XML. Please clue me in what you mean...

          <t>
            A relatively simple policy is to white list known (internal or
            external) domainIDs.
            To require all vouchers to have a nonce.
            Alternatively to require that all nonceless vouchers be from a
            subset (e.g. only internal) domainIDs.
            If the policy is violated a simple action is to revoke any
            locally issued credentials for the pledge in question or to
            refuse to forward the voucher.  The Registrar MUST then refuse
            any EST actions, and SHOULD inform a human via a log.
            A registrar MAY be configured to ignore (i.e. override the above
            policy) the 
            history of the device but it is RECOMMENDED that this only be
            configured if hardware assisted (i.e. TPM anchored) Network
            Endpoint Assessment (NEA) <xref target="RFC5209" /> is supported.
          </t>

    doc>    credentials for the pledge in question or to refuse to forward the
    doc> voucher.  A registrar MAY be configured to ignore the history of the

    > "simple action" in the case that the registrar doesn't like the audit
    > log results?

See changes above for better clarity.

    >    device but it is RECOMMENDED that this only be configured if
    > hardware assisted NEA [RFC5209] is supported.

    > Probably need to expand NEA.

done, see above.

    > Section 5.9

    doc>    Although EST allows clients to obtain multiple certificates by
    doc> sending multiple CSR requests BRSKI mandates use of the CSR Attributes
    doc> request and mandates that the registrar validate the CSR against the
    doc> expected attributes.  This implies that client requests

    > Where is this requirement stated normatively?

I guess I never thought of it as a requirement that multiple certificates are
not supported; it's a restriction because CSR Attributes is used.
Where is use of CSR Attributes stated. RFC7030 Section 4.5 has using CSR
Attributes as a SHOULD.

I will note that the ACME Integration documents all seem to have missed
the CSR Attributes part of the flow.

    Although EST allows clients to obtain multiple certificates by
-   sending multiple CSR requests BRSKI mandates use of the CSR
-   Attributes request and mandates that the registrar validate the CSR
+   sending multiple CSR requests; BRSKI does not support this mechanism
+   directly.  This is because BRSKI pledges MUST use the CSR Attributes
+   request ([RFC7030] section 4.5).  The registrar MUST validate the CSR
    against the expected attributes.  This implies that client requests
    will "look the same" and therefore result in a single logical
    certificate being issued even if the client were to make multiple

    > Section 5.9.1

    doc>    This ensures that the pledge has the complete set of current CA
    doc> certificates beyond the pinned-domain-cert (see Section 5.6.1 for a
    doc> discussion of the limitations inherent in having a single certificate
    doc> instead of a full CA Certificates response.)  Although these

    > I don't see such a discussion in the indicated section.

The 5.6 section got split, it should refer to 5.6.2 now.

    > Section 5.9.2

    doc>    To alleviate these operational difficulties, the pledge MUST request
    doc> the EST "CSR Attributes" from the EST server and the EST server needs
    doc> to be able to reply with the attributes necessary for use of the
    doc> certificate in its intended protocols/services.  This approach allows

    > "intended" implies that the EST server has some knowledge of what the
    > pledge is expected to be doing in the network, right?

Yes.  The ACP document is quite specific about the (rfc822Name) attributes to
assign.  Certainly the attributes could include stuff like
"ve608.core1.tor1.example.net" if the Registrar knew how this device was
to be used, but more likely that would be set up afterwards.

    doc>    To alleviate these operational difficulties, the pledge MUST request
    doc> the EST "CSR Attributes" from the EST server and the EST server needs
    doc> to be able to reply with the attributes necessary for use of the
    doc> certificate in its intended protocols/services.  This approach allows
    doc> for minimal CA integrations and instead the local infrastructure (EST
    doc> server) informs the pledge of the proper fields to include in the
    doc> generated CSR.  This approach is beneficial to automated boostrapping
    doc> in the widest number of environments.

    > This is convenient, but has some security considerations in that it
    > implies that the validation policy on the CA is somewhat lax, since the
    > EST server is expected to be doing most of the policy controls.  Thus,
    > a compromised pledge/device could send a CSR with unauthorized fields
    > and it is likely to be signed, allowing for some level of privilege
    > escalation.  When the registrar acts as a proxy to the CA as well as
    > its EST role, as described later, this risk is diminished.

I don't really understand.
EST servers are Registration Authorities, and they have some kind of
priviledged access to the CA, and are mandated to check the CSR.
I expected to find a statement to this effect in RFC7030, in section 4.2.1,
but I don't see any particularly strong language.
This seems like a quality of implementation issue in the Registrar.

    doc>    In networks using the BRSKI enrolled certificate to authenticate the
    doc> ACP (Autonomic Control Plane), the EST attributes MUST include the "ACP
    doc> information" field.  See [I-D.ietf-anima-autonomic-control-plane] for
    doc> more details.

    > This MUST seems like it belongs in the ACP spec and need not be
    > repeated here using normative language.

I will simplify this, and reference to section 6.1.2 of the ACP.

           <t>In networks using the BRSKI enrolled certificate to authenticate
-          the ACP (Autonomic Control Plane), the EST attributes MUST include
-          the "ACP information" field. See <xref target="I-D.ietf-anima-autonomic-control-plane" /> for more details.</t>
+          the ACP (Autonomic Control Plane), the EST CSR attributes MUST include
+          the ACP Domain Information Fields defined in <xref
+          target="I-D.ietf-anima-autonomic-control-plane" /> section 6.1.2.
+          </t>
 
    > Section 5.9.4

    doc>    administrators concerning device lifecycle status.  This might
    doc> include information concerning attempted bootstrapping messages seen by
    doc> the client, MASA provides logs and status of credential enrollment.
    doc> [RFC7030] assumes an end user and therefore does not

    > This looks like a comma splice.

fixed.

    doc>    In the case of a FAIL, the Reason string indicates why the most
    doc> recent enrollment failed.  The SubjectKeyIdentifier field MUST be
    doc> included if the enrollment attempt was for a keypair that is locally

    > We haven't talked about POSTing to a new status-report endpoing yet, so
    > this comes out of the blue.  It would probably be worth adding above
    > "SHOULD [start a new TLS handshake] and POST a enrollment status
    > message".

So I'll re-order some paragraphs, and I see that there is an obsolete
half-thought, which remained after removing the TLS re-negotiate option that
TLS1.3 obsoletes. 

    >      "Status":TRUE /* TRUE=Success, FALSE=Fail"

    > [same note about JSON comments]

    >      "reason-context": "Additional information"

    > Is this supposed to be a string or a JSON object similar to
    > /voucher_status?

Already fixed to correct JSON from other comments.

    doc>    This allows for clients that wish to minimize their crypto
    doc> operations to simply POST this response without renegotiating the TLS
    doc> session - at the cost of the server not being able to accurately verify
    doc> that enrollment was truly successful.

    > I'd prefer to not have this sort of option available, but I can't
    > disprove the claim of its utility, so I will not object if it stays.

Agreed, I've removed it.

    > Section 5.9.5

    > Is the idea that the initial BRSKI-EST-issued certificate would
    > authenticate the client for the subsequent EST requests?

yes.

    > Section 7

    > If this is non-normative and will need to be fleshed out in a separate
    > document, would an Appendix be more appropriate?

Section 9 and 10 refer back to this section in a normative fashion.

    > Section 7.1

    doc>    Pledge: The pledge could be compromised and providing an attack
    doc> vector for malware.  The entity is trusted to only imprint using secure
    doc> methods described in this document.  Additional endpoint

    > How do "could be compromised" and "is trusted to only [...]" go
    > together?

The IDevID could be safe in a TPM, on the other side of an intact kernel,
but the device could be running a VM full of malware.  We can trust it to
onboard, but not the operate correctly.

    doc>    Vendor Service, MASA: This form of manufacturer service is trusted
    doc> to accurately log all claim attempts and to provide authoritative log
    doc> information to registrars.  The MASA does not know which devices are
    doc> associated with which domains.  These claims could be

    > I think this is maybe more of a "does not enforce" than "does not
    > know", since the domainID ends up in the audit logs that the MASA
    > holds.

Yes, but the domainID does not directly identify the Registrar by name.
Assuming a database breach, what does the MASA know that it can reveal.
The MASA could store more data, but it doesn't have.

    >       Current text provides only for a trusted manufacturer.

    > nit: not a complete sentence.

I have no memory of what it means, so I've removed it.

    > Section 7.3

    doc>    A registrar can choose to accept devices using less secure methods.
    doc> These methods are acceptable when low security models are needed, as
    doc> the security decisions are being made by the local administrator, but
    doc> they MUST NOT be the default behavior:

    > I'm having a hard time parsing "low security models"; the best I can
    > come up with is "threat models where low security is adequate".

    doc>    Lower security modes chosen by the MASA service affect all device
    doc> deployments unless bound to the specific device identities.  In which

    > Is this "unless the lower-security behavior is tied to specific device
    > identities"?

Yes, changed.

    doc>    case these modes can be provided as additional features for specific
    doc> customers.  The MASA service can choose to run in less secure modes

    > nit: This middle sentence is not a complete sentence.

Already fixed.

    doc>    1.  Not enforcing that a nonce is in the voucher.  This results in
    doc> distribution of a voucher that never expires and in effect makes

    > A nonceless voucher can still include an expiration time ... it is just
    > in practice possible for it to never expire, if the target pledge does
    > not have an accurate clock.

Yes, that's correct.
How many devices with RTCs survive 10 years in a warehouse with no power? :-)
Section 7.4 (.1, and .2) have been reworked some more.

    doc>        subsequent bootstrapping attempts.  That this occurred is
    doc> captured in the log information so that the registrar can make
    doc> appropriate security decisions when a pledge joins the Domain.  This is
    doc> useful to support use cases where registrars might not be online during
    doc> actual device deployment.  Because this results in

    > nit: I think that grammatically the "This" at the start of this
    > sentence refers to the behavior described in the previous sentence (the
    > availability of the log information) rather than the issuance of the
    > nonceless voucher.

fixed.

    > Section 9

    doc>    The autonomic control plane that this document provides bootstrap
    doc> for is typically a medium to large Internet Service Provider
    doc> organization, or an equivalent Enterprise that has signficant layer-3
    doc> router connectivity.  (A network consistenting of primarily layer-2

    > nit: "is used in" -- the ACP is not the entire organization!

The text doesn't have "is used in"
But, I did find that paragraph awkward and rewrote it.

    > Section 10.1

    doc>    The MASA audit log includes a hash of the domainID for each
    doc> Registrar a voucher has been issued to.  This information is closely
    doc> related to the actual domain identity, especially when paired with the
    doc> anti-DDoS authentication information the MASA might collect.  This
    doc> could

    > I thought I remembered some discussion of collecting this information
    > and thus what sort of information might be collected, but searching for
    > "DDoS" in the document didn't find it.

In order to protect itself from DDoS attacks, it's better if the MASA
can authenticate every connection.  With full supply chain integration, then
it knows every customer, and this is easy.
On the other hand, if it hasn't got full chain integration, then it may need
to accept connections from any place with any client certificate.  So it
will need some kind of anti-DDOS system.  section 11.1 speaks about this,
although it uses the term DoS.  I've synchronized the terms and made
a forward reference.

    doc>    There are a number of design choices that mitigate this risk.  The
    doc> domain can maintain some privacy since it has not necessarily been
    doc> authenticated and is not authoritatively bound to the supply chain.

    > Is this really "privacy" or just "semi-plausible deniability"?

It's a good question.
A domain could use a new certificate for each device, could connect via some
onion router.  Is that privacy, or "semi-plausible deniability"?

    doc>    Additionally the domainID captures only the unauthenticated subject
    doc> key identifier of the domain.  A privacy sensitive domain could

    > It's interesting to see "unauthenticated" used here, since the domainID
    > is deterministically generated from the pinned-domain-cert that is
    > included in the voucher and inserted into the pledge's trust store.  So
    > in a sense it is a committal by "the domain" to tie that domain cert to
    > that device or have the device otherwise be unusable.

Yes, so a Registrar can present a new self-signed certificate each time.
Sure, it has to keep that around, as it's the link for that pledge.

    > The subsequent
    > text here seems to be suggesting that instead of having a single root
    > CA cert used by all devices in the domain, distinct certs would be used
    > for each device, thus attempting to remove an ability to associate
    > devices with each other via joint domain membership.  One might imagine
    > doing this by entering intermediate CAs (or even leafs?) into the
    > pinned-domain-cert field, but if those certs ever become visible (e.g.,
    > via certificate transparency), then the domainIDs can be independently
    > computed and associated to the MASA audit log, and the issuer chain
    > used to recorrelate the devices by domainID.  So to fully protect
    > privacy, the per-device pinned-domain-certs would need to be "root"s
    > (i.e., self-issued), which greatly increases the manageability
    > complexity and is in effect counter to the goals of ANIMA and BRSKI.

Agreed.
If you have suggestions on other ways to mitigate, I'm all ears.

    > Section 10.2

    doc>    While the contents of the signed part of the pledge voucher request
    doc> can not be changed, they are not encrypted at the registrar.  The
    doc> ability to audit the messages by the owner of the network prevents
    doc> exfiltration of data by a nefarious pledge.  The contents of an

    > I think "prevents" is too strong -- steganography and concealed
    > channels are really hard to completely defend against.  "Gives a
    > mechanism to defend against" would be more accurate, in my opinion.

Okay.

    doc>    The above situation is to be distinguished from a residential/
    doc> individual person who registers a device from a manufacturer: that an
    doc> enterprise/ISP purchases routing products is hardly worth mentioning.
    doc> Deviations would, however, be notable.

    > Deviations in what sense?

After buying only Cisco equipment (like ASR 9000) [observed by number of MASA
connections after each POP turn up], ISP example.net suddendly
has started communicating with Juniper's MASA (for MX40s..).

    > Section 10.3

    doc>    4.  There is a fourth case, if the manufacturer is providing
    doc> protection against stolen devices.  The manufacturer then has a
    doc> responsability to protect the legitimate owner against fraudulent
    doc> claims that the the equipment was stolen.  Such a claim would cause the
    doc> manufacturer to refuse to issue a new voucher.  Should the device go
    doc> through a deep factory reset (for instance, replacement of a damaged
    doc> main board component, the device would not bootstrap.

    > I'm not sure I understand this scenario -- is it talking about where a
    > third party makes a false theft report in the hopes that the real owner
    > will have to do a deep reset and then have the device fail to bootstrap
    > because of the reported theft?

Yes.

    > Section 11

    doc>    To facilitate logging and administrative oversight, in addition to
    doc> triggering Registration verification of MASA logs, the pledge reports

    > I'm not sure if "Registration verification" is a typo or not.

changed to: _Registrar verification_

    doc>    registrar.  This is mandated anyway because of the operational
    doc> benefits of an informed administrator in cases where the failure is
    doc> indicative of a problem.  The registrar is RECOMMENDED to verify MASA

    > I'd also expect some comment about the limited value of the additional
    > information to an attacker in the context where the attacker already
    > would know [other information].

I'm not sure what other "other information" is yet, so I don't know
how to fill that in.

    doc>    To facilitate truely limited clients EST RFC7030 section 3.3.2
    doc> requirements that the client MUST support a client authentication model
    doc> have been reduced in Section 7 to a statement that the registrar "MAY"
    doc> choose to accept devices that fail cryptographic authentication.  This
    doc> reflects current (poor) practices in shipping

    > But section 7 is non-normative!

okay, but now section 9 refers to parts of it normatively.

    doc>    devices without a cryptographic identity that are NOT RECOMMENDED.

    > I guess if we really wanted to disrecommend this practice we could
    > split it out into a separate document that profiles core BRSKI for such
    > usage.

yes.

    > Section 11.1

    doc>    this might be an issue during disaster recovery.  This risk can be
    doc> mitigated by Registrars that request and maintain long term copies of
    doc> "nonceless" vouchers.  In that way they are guaranteed to be able to
    doc> bootstrap their devices.

    > This, of course, comes with a different risk of what is something like
    > a long-term credential existing that needs to be protected and stored.

I partially agree.
Long-term nonceless vouchers still pin a specific domainID.
So they need to available, but they don't need to be private.

    doc>    The issuance of nonceless vouchers themselves creates a security
    doc> concern.  If the Registrar of a previous domain can intercept protocol
    doc> communications then it can use a previously issued nonceless voucher to
    doc> establish management control of a pledge device even after having sold
    doc> it.  This risk is mitigated by recording the issuance of such vouchers
    doc> in the MASA audit log that is verified by the subsequent Registrar and
    doc> by Pledges only bootstrapping when in a factory default state.  This
    doc> reflects a balance between enabling MASA independence during future
    doc> bootstrapping and the security of bootstrapping itself.  Registrar
    doc> control over requesting and auditing nonceless vouchers allows device
    doc> owners to choose an appropriate balance.

    > I would expect some discussion here about nonceless vouchers
    > with/without expiration times.

Added above.

    > I also wonder whether the owner or registrar should expect to be doing
    > soem periodic MASA audit log checking, akin to a CT auditor or monitor.

Yes, but we think falls into quality of implementation.
It's not something worth doing for every Registrary.

    doc>    of specific pledge devices, helps to mitigate this.  Pledge
    doc> signatures on the pledge voucher-request, as forwarded by the registrar
    doc> in the prior-signed-voucher-request field of the registrar
    doc> voucher-request, significantly reduce this risk by ensuring the MASA
    doc> can confirm proximity between the pledge and the registrar making the
    doc> request.  This mechanism is optional to allow for constrained devices.
    doc> Supply chain integration ("know your customer") is an

    > And so the protection is only available when all devices served by the
    > MASA are known to produce signed voucher-requests.

Which is now mandatory.

    doc>    additional step that MASA providers and device vendors can explore.

    > In terms of adding some more crypto to the BRSKI-MASA flow that would
    > prevent unauthenticated DoS?

If every connection is from a known customer, then one can reject the DoS
at the TLS handshake step.

    > Section 11.2

    > I appreciate having this discussion present; thanks!

    doc>    The fake registrar (Rm) can obtain a voucher signed by the MASA
    doc> either directly or through arbitrary intermediaries.  Assuming that

    > I'm not sure what sort of intermediary this is thinking about.

Join Proxies connected to the systems involved.

    doc>    This pledge voucher-request would be 'stale' in that it has a nonce
    doc> that no longer matches the internal state of the pledge.  In order to
    doc> successfully use any resulting voucher the Rm would need to remove the
    doc> stale nonce or anticipate the pledge's future nonce state.  Reducing
    doc> the possibility of this is why the pledge is mandated to generate a
    doc> strong random or pseudo-random number nonce.

    > This gets a bit more complicated to reason about when we assume that a
    > pledge will have multiple voucher requests out in parallel, instead of
    > doing them in sequence and timing out (so that there is literally only
    > one valid nonce at a given time)...

Agreed.
But, we think that doing things serially has too much potential to run
into head-of-queue challenges; the risk is that if devices don't onboard
relatively quickly, then BRSKI will get turned off, not used, or the
vendor might provide some "backdoor"

    doc>    Additionally, in order to successfully use the resulting voucher the
    doc> Rm would have to attack the pledge and return it to a bootstrapping
    doc> enabled state.  This would require wiping the pledge of current

    > .... and I think there is a different attack if the Rm is in a position
    > to delay or drop network traffic between the pledge and the intended
    > registrar, to cause Rm's voucher to be delivered first even though it
    > is generated after the intended registrar's authorization process.  The
    > intended registrar would need to require reports on voucher processing
    > status (or investigate their absence) in order to detect such a case.

Yes, that's definitely a problem.  We had a lot of difficulty constructing
this attack, btw.

    doc>    o Retreival and examination of MASA log information upon the
    doc> occurance of any such unexpected events.  Rm will be listed in the logs
    doc> along with nonce information for analysis.

    > How strongly guaranteed is it that a given device will only have a
    > single specific MASA that it trusts to issue vouchers (and thus limit
    > the scope of monitoring needed by the owner)?

There is no guarantee; a device could have multiple IDevID.
However, a voucher-request from one wouldn't be useable for another.
It would require malicious code in the pledge, I think.

    > Section 11.3

    doc>    o A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
    doc> upon seeing a manufacturer's trust anchor for the first time, and then
    doc> the trust anchor would be installed to the trusted store.  There are
    doc> risks with this; even if the key to name is validated using something
    doc> like the WebPKI, there remains the possibility

    > nit: is this "key to name mapping"?

fixed.

    > Section 11.4

    > It is not entirely clear to me whether device manufacturers are set up
    > with incentives to maintain a well-run secure CA with strong hardware
    > protections on the offline signing key for the root CA, cycling through
    > various levels of intermediates, etc., that CAs in the Web PKI do
    > today.  If the manufacturer uses a less stringent process, that would
    > leave the manufacturer's key as a more tempting attack surface, and it
    > may be worth some discussion here about what damage could be done with
    > a compromised MASA signing key.  E.g., would an attack require
    > restoring devices to factory defaults or otherwise waiting for natural
    > bootstrapping events to occur?  Would the attacker need to be on-path?
    > Etc.

I have dug around cabforum.org and root-servers.org for some references on
what a "well-run secure CA" should be doing... surprisingly I didn't find an
RFC, or one for DNSSEC root operation. Did I miss them?  I thought that there
was one.  I'm writing some text, and I'll finish this email here, and post
the resulting text.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Aug 2019 15:30:13 -0400

WG: there is a chunk of Security Considerations text here that I hope
many will read.  

    > bootstrapping events to occur?  Would the attacker need to be on-path?

I wanted to add that I think that there are some interesting economic
discussions about these incentives.  I wonder how to interest some people
into doing some analysis of a monetary rather that technical manner.

I have added:
     11.4.  Manufacturer Maintenance of trust anchors  . . . . . . .  75
       11.4.1.  Compromise of Manufacturer IDevID signing keys . . .  77
       11.4.2.  Compromise of MASA signing keys  . . . . . . . . . .  77
       11.4.3.  Compromise of MASA web service . . . . . . . . . . .  79

and this text is rough, and as yet unreviewed by anyone, and I 

11.4.  Manufacturer Maintenance of trust anchors

   BRSKI depends upon the manufacturer building in trust anchors to the
   pledge device.  The voucher artifact which is signed by the MASA will
   be validated by the pledge using that anchor.  This implies that the
   manufacturer needs to maintain access to a signing key that the
   pledge can validate.

   The manufacturer will need to maintain the ability to make signatures
   that can be validated for the lifetime that the device could be
   onboarded.  Whether this onboarding lifetime is less than the device

   lifetime depends upon how the device is used.  An inventory of
   devices kept in a warehouse as spares might not be onboarded for many
   decades.

   There are good cryptographic hygiene reasons why a manufacturer would
   not want to maintain access to a private key for many decades.  A
   manufacturer in that situation can leverage a long-term certificate
   authority anchor, built-in to the pledge, and then a certificate
   chain may be incorporated using the normal CMS certificate set.  This
   may increase the size of the voucher artifacts, but that is not a
   significant issues in non-constrained environments.

   There are a few other operational variations that manufacturers could
   consider.  For instance, there is no reason that every device need
   have the same set of trust anchors pre-installed.  Devices built in
   different factories, or on different days, or any other consideration
   could have different trust anchors built in, and the record of which
   batch the device is in would be recorded in the asset database.  The
   manufacturer would then know which anchor to sign an artifact
   against.

   Aside from the concern about long-term access to private keys, a
   major limiting factor for the shelf-life of many devices will be the
   age of the cryptographic algorithms included.  A device produced in
   2019 will have hardware and software capable of validating algorithms
   common in 2019, and will have no defense against attacks (both
   quantum and von-neuman brute force attacks) which have not yet been
   invented.  This concern is orthogonal to the concern about access to
   private keys, but this concern likely dominates and limits the
   lifespan of a device in a warehouse.  If any update to firmware to
   support new cryptographic mechanism were possible (while the device
   was in a warehouse), updates to trust anchors would also be done at
   the same time.

   The set of standard operating proceedures for maintaining high value
   private keys is well documented.  For instance, the WebPKI provides a
   number of options for audits at {{cabforumaudit}}, and the DNSSEC
   root operations are well documented at {{dnssecroot}}.

   It is not clear if Manufacturers will take this level of precaution,
   or how strong the economic incentives are to maintain an appropriate
   level of security.

   This next section examines the risk due to a compromised MASA key.
   This is followed by examination of the risk of a compromised
   manufacturer IDevID signing key.  The third section sections below
   examines the situation where MASA web server itself is under attacker
   control, but that the MASA signing key itself is safe in a not-
   directly connected hardware module.

11.4.1.  Compromise of Manufacturer IDevID signing keys

   An attacker that has access to the key that the manufacturer uses to
   sign IDevID certificates can create counterfeit devices.  Such
   devices can claim to be from a particular manufacturer, but be
   entirely different devices: Trojan horses in effect.

   As the attacker controls the MASA URL in the certificate, the
   registrar can be convinced to talk to the attackers' MASA.  The
   Registrar does not need to be in any kind of promiscuous mode to be
   vulnerable.

   In addition to creating fake devices, the attacker may also be able
   to issue revocations for existing certificates if the IDevID
   certificate process relies upon CRL lists that are distributed.

   There does not otherwise seem to be any risk from this compromise to
   devices which are already deployed, or which are sitting locally in
   boxes waiting for deployment (local spares).  The issue is that
   operators will be unable to trust devices which have been in an
   uncontrolled warehouse as they do not know if those are real devices.

11.4.2.  Compromise of MASA signing keys

   There are two periods of time in which to consider: when the MASA key
   has fallen into the hands of an attacker, and after the MASA
   recognizes that the key has been compromised.

11.4.2.1.  Attacker opportunties with compromised MASA key

   An attacker that has access to the MASA signing key could create
   vouchers.  These vouchers could be for existing deployed devices, or
   for devices which are still in a warehouse.  In order to exploit
   these vouchers two things need to occur: the device has to go through
   a factory default boot cycle, and the registrar has to be convinced
   to contact the attacker's MASA.

   If the attacker controls a Registrar which is visible to the device,
   then there is no difficulty in delivery of the false voucher.  A
   possible practical example of an attack like this would be in a data
   center, at an ISP peering point (whether a public IX, or a private
   peering point).  In such a situation, there are already cables
   attached to the equipment that lead to other devices (the peers at
   the IX), and through those links, the false voucher could be
   delivered.  The difficult part would be get the device put through a
   factory reset.  This might be accomplished through social engineering
   of data center staff.  Most locked cages have ventilation holes, and
   possibly a long "paperclip" could reach through to depress a factory
   reset button.  Once such a piece of ISP equipment has been
   compromised, it could be used to compromise equipment that was
   connected to (through long haul links even), assuming that those
   pieces of equipment could also be forced through a factory reset.

   The above scenario seems rather unlikely as it requires some element
   of physical access; but were there a remote exploit that did not
   cause a direct breach, but rather a fault that resulted in a factory
   reset, this could provide a reasonable path.

   The above deals with ANI uses of BRSKI.  For cases where 802.11 or
   802.15.4 is involved, the need to connect directly to the device is
   eliminated, but the need to do a factory reset is not.  Physical
   possession of the device is not required as above, provided that
   there is some way to force a factory reset.  With some consumers
   devices with low overall implementation quality, the end users might
   be familiar with needing to reset the device regularly.

   The authors are unable to come up with an attack scenario where a
   compromised voucher signature enables an attacker to introduce a
   compromised pledge into an existing operator's network.  This is the
   case because the operator controls the communication between
   Registrar and MASA, and there is no opportunity to introduce the fake
   voucher through that conduit.

11.4.2.2.  Risks after key compromise is known

   Once the operator of the MASA realizes that the voucher signing key
   has been compromised it has to do a few things.

   First, it MUST issue a firmware update to all devices that had that
   key as a trust anchor, such that they will no longer trust vouchers
   from that key.  This will affect devices in the field which are
   operating, but those devices, being in operation, are not performing
   onboarding operations, so this is not a critical patch.

   Devices in boxes (in warehouses) are vulnerable, and remain
   vulnerable until patched.  An operator would be prudent to unbox the
   devices, onboard them in a safe environment, and then perform
   firmware updates.  This does not have to be done by the end-operator;
   it could be done by a distributor that stores the spares.  A
   recommended practice for high value devices (which typically have a
   <4hr service window) may be to validate the device operation on a
   regular basis anyway.

   If the onboarding process includes attestations about firmware
   versions, then through that process the operator would be advised to
   upgrade the firmware before going into production.  Unfortunately,
   this does not help against situations where the attacker operates
   their own Registrar (as listed above).

   [RFC8366] section 6.1 explains the need for short-lived vouchers.
   The nonce guarantees freshness, and the short-lived nature of the
   voucher means that the window to deliver a fake voucher is very
   short.  A nonceless, long-lived voucher would be the only option for
   the attacker, and devices in the warehouse would be vulnerable to
   such a thing.

   A key operational recommendation is for manufacturers to sign
   nonceless, long-lived vouchers with a different key that they sign
   short-lived vouchers.  That key needs significantly better
   protection.  If both keys come from a common trust-anchor (the
   manufacturer's CA), then a compromise of the manufacturer's CA would
   be a bigger problem.

11.4.3.  Compromise of MASA web service

   An attacker that takes over the MASA web service has a number of
   attacks.  The most obvious one is simply to take the database listing
   customers and devices and to sell this data to other attackers who
   will now know where to find potentially vulnerable devices.

   The second most obvious thing that the attacker can do is to kill the
   service, or make it operate unreliably, making customers frustrated.
   This could have a serious affect on ability to deploy new services by
   customers, and would be a significant issue during disaster recovery.

   While the compromise of the MASA web service may lead to the
   compromise of the MASA voucher signing key, if the signing occurs
   offboard (such as in a hardware signing module, HSM), then the key
   may well be safe, but control over it resides with the attacker.

   Such an attacker can issue vouchers for any device presently in
   service.  Said device still needs to be convinced to do through a
   factory reset process before an attack.

   If the attacker has access to a key that is trusted for long-lived
   nonceless vouchers, then they could issue vouchers for devices which
   are not yet in service.  This attack may be very hard to verify and
   as it would involve doing firmware updates on every device in
   warehouses (a potentially ruinously expensive process), a
   manufacturer might be reluctant to admit this possibility.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Aug 2019 16:23:54 -0400

Benjamin Kaduk via Datatracker <[email-masked]> wrote:
    > Section 13.2

    > I think CDDL needs to be a normative reference, as does RFC 7231.  RFC
    > 2473 is listed but not referenced in the text, as are RFC 2663, RFC
    > 7217, and RFC 7575.

CDDL->RFC8610, now normative. (Glad that got published)
RFC2473 removed, we no longer attempt to document a stateless IPIP proxy
mechanism.

RFC2663 (NAT terminology) reference was for Join Proxy, and I've restored
a reference in section 4.

RFC7217 was thought to be relevant to Pledge use of SLAAC, but actually it's
not, removed.

You are right that we don't reference RFC7575, which is the architecture of
ANIMA.  I have added a sentence to the Intro, referencing RFC7575's
goal of "secure by default"

    > Appendix B

    doc>    Discovery of registrar MAY also be performed with DNS-based service
    doc> discovery by searching for the service "_brski-
    doc> registrar._tcp.example.com".  In this case the domain "example.com" is
    doc> discovered as described in [RFC6763] section 11 (Appendix A.2 suggests
    doc> the use of DHCP parameters).

    > I'd suggest using "<domain>" per 6763 rather than "example.com".

okay.

    doc>    If no local proxy or registrar service is located using the GRASP
    doc> mechanisms or the above mentioned DNS-based Service Discovery methods
    doc> the pledge MAY contact a well known manufacturer provided bootstrapping
    doc> server by performing a DNS lookup using a well known URI such as
    doc> "brski-registrar.manufacturer.example.com".  The details of the URI are
    doc> manufacturer specific.  Manufacturers that leverage this method on the
    doc> pledge are responsible for providing the registrar service.  Also see
    doc> Section 2.7.

    > It seems like there are some security considerations for device owners
    > that may wish to prevent such registrars from being used.  Do we need
    > to direct them to run a firewall or similar?

If they are doing ANIMA ACP bootstrapping, then there would ideally be no
IPv4 available, and so this won't work anyway.
I'd rather not get into too much of this here.

    > Appendix C

    > I don't know how important file "[email-masked]"
    > is, but it seems a tad generic.

Renamed already.

Ben, I'm posting the -25, and then moving on back to the responses to
my responses, including Adam's concerns.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Aug 2019 11:37:47 -0400

Adam Roach <[email-masked]> wrote:
    >> Adam Roach:    https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA
    >> ...
    >> This is an rfcdiff from the already-wrapped JSON to the proposed -23 that
    >> includes all the changes from the various DISCUSSes up to now:
    >> https://tinyurl.com/y2qhjwh8

    > As a quick note -- the diff above does not address the "discuss" part of my
    > second discuss point: the document remains ambiguous regarding *how* the URL
    > is to be returned. The lengthy parenthetical references added to the
    > corresponding paragraph aren't sufficient to positively indicate that the URL
    > appears in a "Location" header: this needs to be stated explicitly rather
    > than implied by a section reference.

I had previously updated to point to RFC7231 section 6.3.2, but upon careful
reading, I see that returning the URL in the Location: is not mandated by
6.3.2.  I am a little bit surprised that 7231 is so vague on what I thought
was a pretty much written in stone process....

         <t>
           Rather than returning the audit log as a response to the POST (with
           a return code 200), the MASA MAY instead return a 201 ("Created")
-          response (<xref target="RFC7231" /> sections 6.3.2 and 7.1) containing
-          a URL to the prepared (and idempotent, therefore cachable) audit response.
+          response (<xref target="RFC7231" /> sections 6.3.2 and 7.1), with
+          the URL to the prepared (and idempotent, therefore cachable) audit
+          response in the Location: header.
         </t>

Does this fix things for you?

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Aug 2019 12:25:33 -0500

>    trust anchors to be pre-configured on a per-vendor basis.

That works for me ... or perhaps, "great minds think alike"?

>     > It would be great to have some, there!

Oh, the "not verifying ownership" part?  I somehow was interpreting that as
"we still require client authentication, but don't have a fancy database
mapping owner to hardware, so any authenticated registrar can get a
voucher for any device".

> could be forward referenced.  Diff too long here, see link above.

The text in the diff is more clear about what is going on, thanks.  (Though
I think "tradeoffs" is usually just written as one word.)

> preferred), says who is asking.

Well, I think a lot of my confusion stemmed from the lack of advance
definition of "MASA Audit Log" as a protocol element, which you already
fixed.  So what's left would seem to mostly be a question of whether
something about "access control" vs. "authorization to access the relevant
subset of the audit log" is a more accurate description of what's going on.
That is, whether "access control" is something done by a server (MASA)-side
agent applying policy, or ... something else that I don't know how to
describe well.

>       request.  This field provides additional information to the MASA.

Hmm, I'm trying to look for why I claimed that "earlier we said that this
field would be propagated".  Section 3.3 (of the -22)'s Example (2) says
"[t]he nonce, created-on and assertion is carried forward", and Section 5.2
wants pledges to populate it as well.  So the idea is that the MASA is only
going to get the pledge's created-on via the prior-signed-voucher-request
(if present)?
I'm confused about what it means to "carry forward" the created-on if the
registrar is populating it anew, though.

>    idevid-issuer:  The Issuer value from the value from the pledge

nit: duplicated "value from the"

> Correct, it's from the pledge->registrar.

So it's more of a "MUST NOT" than a "MAY not", here?

> such entities, then it just doesn't.

The audit log is a defense against this in that it allows for post-facto
discovery of misuse?  Or is there some pre-issuance authorization check
going on.
I think I may need some section references to where the authorization
policy (options) are documented; I've lost a bit of state on this one.

> I've added a few words to say this.

Ah, that helps a lot.

> no prior-signed-voucher-request field is needed.  If it's there, then it must

Sure.
(But what does "consistent with" mean?)

> So I've removed the last sentence completely

I'm not entirely sure I follow why this means that the last sentence is
okay to remove, but it's probably okay.
(Also, I could imagine a case where a third-party "assigned" MASA gets an
incomplete feed of device capabilities/behavior from the manufacturer, even
by accident, so "by construction" is perhaps stronger than I would use.)

> I think that 5.5.2 is the right pointer.

Oh, I seem to have completely missed that part; sorry.
So then 5.5 (not 5.5.2) is the right reference, and the line removed from
5.5.2 should get restored.

> for resistence to pre-image attacks) as a last resort.

Sorry, I'm still not seeing the justification for using SHA-1 as the
fallback instead of (e.g.) SHA-256.  If the SKI is present, then definitely
use that.  But if it's not present, we can define whatever we want, can't
we?  It's not like "The keyIdentifier is composed of the 256-bit SHA-256
hash of the value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits)" is an unreasonable amount of text ot
include in the document.  Now, if there's some backwards compatibility need
or implementation challenge, we can talk about that, but all I'm seeing so
far is blind adherence to an 11-year-old document for consistency's sake,
and in this case I don't think consistency outweighs cryptographic
modernization.

>               used as a DomainID, and that a hash stronger than SHA-1 be

I guess I don't see anywhere better to do this, so thanks.

> supply chain integration.

Do you want to make any changes to the text, perhaps "due to a mismatch
with intventory [contro]"?

>           field.  Such a thing indicates a failure to enroll in this domain,

Looks good, thanks (but maybe s/thing/response/?)

> The 5.9.4 Enrollment Status Telemtry is not, because enrollment is not mandatory.

Ah, sorry for the confusion.

:)

> mechanism would be interesting, but we don't know what exactly are the

Thanks for the discussion; it helps clarify the picture to me.
Can we maybe just say "requestor" instead of "requesting owner", then?

> Stay tuned for tomorrow's exciting episode.

My breath would be bated if I was not so sluggish to reply...

-Ben

---

From: Adam Roach <[email-masked]>
Date: Tue, 13 Aug 2019 12:31:02 -0500

> Does this fix things for you?

Yes, thanks. One minor nit: "...Location: header field."

/a

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Aug 2019 17:07:46 -0400

Benjamin Kaduk <[email-masked]> wrote:
    doc> The authentication of the BRSKI-MASA connection does not affect the
    doc> voucher-request process, as voucher-requests are already signed by
    doc> the registrar.  Instead, this authentication provides access control
    doc> to the audit log.

    > agent applying policy, or ... something else that I don't know how to

I have added a forward reference in section 5.4 to section 5.8 around the
the access control question.

    
    > registrar is populating it anew, though.

I have changed the text:

-                here it must be base64 encoded. The nonce, created-on and
-                assertion is carried forward. The serial-number is extracted
-                from
+                here it must be base64 encoded. The nonce and
+                assertion MAY be carried forward from the pledge request to
+                the registrar request.
+                The serial-number is extracted from

It is a MAY, because in a case where the Registrar wants a nonceless voucher,
then it won't include a nonce.

fixed.

    > So it's more of a "MUST NOT" than a "MAY not", here?

added:
        <t>
          The "proximity-registrar-cert" field MUST NOT be present in the
          registrar voucher-request.
        </t>

    > policy (options) are documented; I've lost a bit of state on this one.

That's right, the audit log provides discovery of mis-use.
The check belongs prior to issurance of an LDevID, and may be repeated
regularly afterwards.

I think you are asking for a list of MASA authorization policy options.
We do not have such a menu of options, and I'm reluctant to write them
down normatively at this point, as I think that there are combinations we do
not yet understand.

5.5.3 points out that nonceless vouchers need more authorization.
Other parts of 5.5 provide other options.
Please let me know if you think this is insufficient for a Proposed Standard.

BTW: I have started two non-normative (BCP?) documents on Operational
     Considerations for MASA and Registrar.  Started, meaning I've done "mkdir"
     and "git init-db"... I imagine keeping these documents open for quite some
     time.  I've talked about such documents in ANIMA for at least a year.

    > (But what does "consistent with" mean?)

I understand the issue now.
It means either memcmp()==0 or (same Issuer, same Subject).
Surprisingly, 5280 does not have a term for the later!
{discussion with Max ensues.  RFC7469 (HTTP pinning) has a proceedure.

--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -2113,12 +2113,22 @@ locator3  = [O_IPv6_LOCATOR, fe80::1234, 41,
nil]]]></artwork>
+          <t>
+            The consistency check described above is the same
+            process as described in <xref target="RFC7469" /> section 2.6.
+            Regardless of how the consistency check was done, the MASA MUST
+            use the serialized value from the
+            proximity-registrar-cert (in the prior-signed-voucher-request)
+            when forming the voucher, as that is the only value that
+            the Pledge will have.
+          </t>

    > by accident, so "by construction" is perhaps stronger than I would use.)

The sentence says that MASA should should if the pledge can sign, and if it
does not sign, then it would know if that's okay.  But since signing is now
not optional, that consideration does not apply.

You are correct that an outsourced MASA might not have a complete list, but I
think that is out of scope.

    > we?

I'm trying not be seen as an Update to RFC5280 :-)
Continued in next email.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Aug 2019 10:05:13 -0400

> fallback instead of (e.g.) SHA-256.  If the SKI is present, then
    > definitely use that.  But if it's not present, we can define whatever
    > we want, can't we?  It's not like "The keyIdentifier is composed of the
    > 256-bit SHA-256 

Hi, we have revised the text, making use of section 2.4 from rfc7469, which
has a similar need.

We added a new section 5.8.2, calculation of domainID:

5.8.2.  Calculation of domainID

   The domainID is a binary value (a BIT STRING) that uniquely
   identifies a Registrar by the "pinned-domain-cert"

   If the "pinned-domain-cert" certificate includes the
   SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
   used as the domainID.  If not, then it is the SPKI Fingerprint as
   described in [RFC7469] section 2.4 is to be used.  This value needs
   to be calculated by both MASA (to populate the audit-log), and by the
   Registrar (to recognize itself).

   [RFC5280] section 4.2.1.2 does not mandate that the
   SubjectKeyIdentifier extension be present in non-CA certificates.  It
   is RECOMMENDED that Registrar certificates (even if self-signed),
   always include the SubjectKeyIdentifier to be used as a domainID.

   The domainID is determined from the certificate chain associated with
   the pinned-domain-cert and is used to update the audit-log.

and referenced this section in the terminology.  This eliminates all
references to SHA-1.  RFC7469 section 2.4 uses SHA-256.

We also strengthened our statement that the SubjectKeyIdentifier SHOULD
exist.  In the process, we recognized that we had some mismatch in
(MY) thinking about pinned-domain-cert, thinking it was always the
Registrar End-Entity Certificate, when in fact it is the Registrar's
CA certificate.  As a CA certificate, it SHOULD always have the
SubjectKeyIdentifier.

We are presenting discussing whether the EE Registrar cert should get
audited.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Aug 2019 09:27:38 -0500

>     > If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data".

(Well, 8529, but I think we covered that already.)

> As in, what should occur if the "version" is not 1?

Exactly so!

> request.    This is down in (what is now) Figure 4.

Thinking about it that way is very helpful; thank you.

Okay.

> I don't know where the "of" that is missing goes.

"subset of" (though possibly split by the parenthetical)

> See changes above for better clarity.

And greater clarity is achieved; thanks.

> +   sending multiple CSR requests; BRSKI does not support this mechanism

nit: comma, not semicolon  (because the sentence starts with "although").

> +   directly.  This is because BRSKI pledges MUST use the CSR Attributes

(This may not need to be a 2119 MUST since we cite 7030.)

> +   request ([RFC7030] section 4.5).  The registrar MUST validate the CSR

but this change does address my concern, so thank you.

> to be used, but more likely that would be set up afterwards.

Hmm, maybe later when we say "the local infrastructure (EST server) informs
the pledge of the proper fields to include in the generated CSR" we could
reiterate that the EST server has local configuration information to inform
this messaging, though it's probably not necessary.

> This seems like a quality of implementation issue in the Registrar.

The high-level intended workflow described here is roughly "(1) pledge asks
registrar for config; (2) pledge puts that config in a CSR, signs the CSR,
and sends the CSR to registrar; (3) registrar passes CSR to CA using
registrar's implicit authority.  We don't describe any crypto to check that
(2) happens as intended, as opposed to the pledge dishonestly claiming "oh,
and I'm a CA" or "I can provide all ACP services, even privileged ones", so
that has to be done by policy in the registrar, as you note.  I'm wary of
suggesting the workflow that relies on the registrar's implicit authority
at the CA without also noting the registrar's policy enforcement
obligations.  Though it's possible this is covered elsewhere and doesn't
need to be duplicated here.

> +          target="I-D.ietf-anima-autonomic-control-plane" /> section 6.1.2.

(beating the dead horse, is this any different as "MUST include" vs.
"include"?)

> Section 9 and 10 refer back to this section in a normative fashion.

Er, wouldn't that make this section no longer non-normative?
(Not that I could find the references you're talking about, so a clue bat
is welcome.)

> Assuming a database breach, what does the MASA know that it can reveal.

can reveal or be correlated with other sources of information.  The
domainID is derived from the public part of a certificate, which could well
be widely disseminated.  An attacker that compromises the MASA and retains
a presence can watch requests come in and backsolve from domainID to
certificate directly.

> How many devices with RTCs survive 10 years in a warehouse with no power? :-)

The ones with a radioisotope thermoelectric generator? ;)

> The text doesn't have "is used in"

(Right, I was saying that you should add it.  But the reworking fixes the
nit, so this is all good.)

> although it uses the term DoS.  I've synchronized the terms and made

Ah, thanks for the pointer to 11.1.

> onion router.  Is that privacy, or "semi-plausible deniability"?

It might depend on the details of the certificates used, what CA issued
them (and its policies regarding accuracy and level of detail in
certificates issued therefrom), and whether the certifciates are
used/exposed for any other purposes.  So, I don't insist on any specific
language, and was just sharing my thoughts about how it is possible to
think about this, in case it sparked any insight.

> If you have suggestions on other ways to mitigate, I'm all ears.

My tentative conclusion so far has been that robust mitigation is going to
be operationally expensive, to the point that I personally would make the
tradeoff of documenting risk and not trying to do a whole lot of
mitigation.  So no brilliant ideas here, unfortunately :-/

> has started communicating with Juniper's MASA (for MX40s..).

So like "deviations from a historical trend" or "deviations from an
established baseline"?

>     > because of the reported theft?

I think having "In the absence of such manufacturer protection, such a
claim would cause [...]" would have helped me get there.

> I'm not sure what other "other information" is yet, so I don't know

IIUC, this text is predicated on a "possibly malicious registrar" that
a pledge tries to register using/through but fails.  So that registrar is
already in a position where the pledge would try to use it -- in the ACP
case, that probably means fairly physically proximate, and maybe implies a
link-local connection.  In the non-ACP case, maybe it also implies
proximity?  I don't know if we can get physical vs. network proximity
implied by a pledge trying to use a registrar, but maybe sometimes.  My
implied question is basically "what else would an attacker have to do to
get a pledge to try to use it as a registrar, and what does the attacker
already have access to by the time it gets that far?"  So we can set the
information learned from voucher parsing status reports in the context of
what else the attacker would already know.  But I don't have the best
picture on the deployment scenarios here, so I can't answer the question
myself :)

> So they need to available, but they don't need to be private.

It's not entirely clear to me that it's okay to make them totally public
(but maybe I am missing something).  That is, in that once the voucher is
public, anyone who can get next to the device can re-bootstrap it using
that voucher, which possibly gets it into a configuration that's not usable
in its current location, and (less likely) maybe it's hard for the real
owner to get the correct configuration back (if the original MASA is gone
or whatever).  So the voucher is not something I'd want to just put on a
public web site.  But I guess maybe you don't have to protect it to the
same extent that you do your crypto keys.

Sure.

>     > MASA are known to produce signed voucher-requests.

Yay

> vendor might provide some "backdoor"

That's a fair concern, but in and of itself is not an excuse to skip
reasoning through the risks of the parallel workflow.  How much effort has
already been spent doing that reasoning through?  For example, one might
want to require that the pledge track which nonce belongs to the voucher
request submitted through which candidate registrar, but I didn't work
through whether that actually will defend against any attack scenarios.

> It would require malicious code in the pledge, I think.

I'm willing to consider malicious code in the pledge as part of my threat
model :)

> was one.  I'm writing some text, and I'll finish this email here, and post

I think I had always assumed this was part of the CA/B forum baseline
requirements (https://cabforum.org/baseline-requirements-documents/) but
never actually looked. :-/
We could ask around if it's important (but I don't think there's an RFC).

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Aug 2019 09:34:04 -0500

> references to SHA-1.  RFC7469 section 2.4 uses SHA-256.

Thank you!

> CA certificate.  As a CA certificate, it SHOULD always have the

My recollection was that it was expected to be a certificate in the
Registrar's chain, probably a CA certificate but possibly an intermediate
one (i.e., not self-signed).  (And I see in 5280 "this extension MUST
appear in all conforming CA certificates".)

> We are presenting discussing whether the EE Registrar cert should get

Okay, sounds good.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Aug 2019 09:52:58 -0500

> and this text is rough, and as yet unreviewed by anyone, and I 

(not sure if there was supposed to be much more to that sentence).

It's rough, sure, but generally looks quite good in terms of content coverage.

>    boxes waiting for deployment (local spares).  The issue is that

(That is, if the boxes are already in local storage at the time of first
compromise)

>    voucher through that conduit.

This seems predicated on the attacker having the MASA signing key but not
persistent control of the (formerly?) legitimate MASA service, right?

>    manufacturer's CA), then a compromise of the manufacturer's CA would

(probably some wordsmithing options for "be a bigger problem")

>    manufacturer might be reluctant to admit this possibility.

Thanks for writing this up!

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Aug 2019 09:56:10 -0500

> I'd rather not get into too much of this here.

I'm not sure I see how v6-only prevents URI dereference or obviates the
usecase for a firewall.  Perhaps you mean that there would be no
non-link-local available?

> my responses, including Adam's concerns.

Okay, thanks.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Aug 2019 10:12:17 -0500

Apparently I only have one comment buried inline.  We must be making
progress :)

> Please let me know if you think this is insufficient for a Proposed Standard.

I think I'd like to see a small addition after/near "[t]his verification is
only a consistency check that the unauthenticated domain CA intended the
voucher-request signer to be a registrar" (perhaps at the end of the
paragraph?) noting something like "since the domain CA is unauthenticated
to the MASA, depending on MASA policy, vouchers not authorized by the
pledge owner may be issued; the MASA audit log can be used to detect such
missisuance".

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Aug 2019 11:38:48 -0400

https://tinyurl.com/y2skc9xz

    > *** MAX ***

We have simplified the text, removed the TPM and Hardware Module Name, etc.
and clarified why we are referencing the LDAP RFC.

We have left an out that says that the Registrar may need to dig elsewhere
on a per-manufacturer basis.

    > I have an open request to *** MAX *** to clarify this part.

We have resolved by this removing the reference to RFC6125.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Aug 2019 12:56:58 -0400

Benjamin Kaduk <[email-masked]> wrote:
    >> We did not resort to a YANG data model for the auditlog responses, so I spent
    >> a few minutes mystified by your complaint... then:
    >> We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 (JSON)!

    > Oh!  That would make  a lot more sense... (but 7159 is obsoleted by 8259,
    > of course)

got them all now.

    >> If so, the reason for normative language is because, we want to say, "if you
    >> do X, then you MUST do it this way".
    >>
    >> Second, we have referenced some pieces of section 7.2 from section 9.
    >> We think that there are significant security issues by accepting nonceless
    >> vouchers, which we discuss in 11.1.   A variation of the protocol is when
    >> the manufacturer programs the pledge to ALWAYS accept nonceless vouchers.
    >> There could otherwise be some more complex (proprietary, or documented later
    >> on) evaluation of whether to accept a nonceless voucher. For instance, the
    >> MASA could sign them with a different key, perhaps one stored in an HSM.

    > Okay, so it is that the client (well, manufacturer?) chooses whether or not
    > to accept nonceless vouchers.  So we could change the introduction to the
    > enumerated list to be saying that this is a list of exclusive candidate
    > behaviors that could be chosen independently of each other, and not a
    > collection of behaviors all of which are expected to be implemented.

I have revised section 7.2.
My use of normative language seems inconsistent at this point.  I need to
distinguish between "X is possible" from "when doing X you MUST Y" better.

    >> > (14) In Section 5.6:
    >>
    >> >                             The server MUST answer with a suitable 4xx
    >> > or 5xx HTTP [RFC2616] error code when a problem occurs.  In this case,
    >> > the response data from the MASA MUST be a plaintext human- readable
    >> > (ASCII, English) error message containing explanatory information
    >> > describing why the request was rejected.
    >>
    >> > It seems hard to support this stance on internationalization in 2019.
    >>
    >> We don't believe that this response will go anywhere other than logs,
    >> for software suppliers to evaluate.  Localizing these error message causes
    >> more problems in my experience than benefit.  90% of the information is in
    >> the 4xx/5xx code.

    > I should probably defer to my ART-area colleagues here.  But you're saying
    > that mandating English is better than allowing  UTF-8 and otherwise leaving
    > it as implementation defined?

We have removed "ASCII, English), and left this as "UTF-8", with the
expectation that the message may be localized.  Emphasis is on human readable.

    >> > (15) In Section 5.9.4:
    >>
    >> >    To indicate successful enrollment the client SHOULD re-negotiate the
    >> > EST TLS session using the newly obtained credentials.  This occurs by
    >> > the client initiating a new TLS ClientHello message on the existing TLS
    >> > connection.  The client MAY simply close the old TLS session and start
    >> > a new one.  The server MUST support either model.
    >>
    >> > Is this supposed to be sending a new TLS ClientHello in the application
    >> > data channel or as a new handshake message (aka "renegotiation")?  The
    >> > latter is not possible in TLS 1.3 and is generally disrecommended
    >> > anyways even in TLS 1.2.  I would strongly suggest to remove the
    >> > "renegotiation" option and just leave "close the connection and start a
    >> > new connection/handshake".
    >>
    >> Okay, fixed to say:
    >>
    >> <t>To indicate successful enrollment the client SHOULD re-negotiate
    >> the EST TLS session using the newly obtained credentials. This
    >> -          occurs by the client initiating a new TLS ClientHello message on the
    >> -          existing TLS connection. The client MAY simply close the old TLS
    >> -          session and start a new one. The server MUST support either
    >> +          occurs by the client closing the existing TLS connection, and
    >> +          starting a new one. The server MUST support either
    >> model.</t>

    > I'd prefer to s/re-negotiate/re-establish/ as well, but this is probably
    > good enough to clear the discuss.

Changed.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Aug 2019 21:10:26 -0400

> of BRSKI in other situations.

we added the following to the end of the point list:
          <t>
            Based upon the above information, the manufacturer is able to
            track a specific device from pseudonymous domain identity to the
            next pseudonymous domain identity.  If there is sales-channel
            integration, then the identities are not pseudonymous.
          </t>

    > look at what signed the IDevID and apply a whitelist of known, verified,

One either has a list of trusted manufacturers or one does not.
This can be done via a list of trust anchors for the IDevID signing entity,
or can be done via a list of trust anchors for the MASA URL.

If not (in a residential use of BRSKI perhaps), then there has to be some
process by which a not previously known manufacturer can become trusted.
There are a great number of layer-8 or layer-9 solutions for this,
perhaps involving new industry CAs or attestations, or ...  I think it is out
of scope.
(for instance RFC5280 section 4.2.2.1 could provide the right references,
but this section has not been well used as yet.  Or we could extend the
MASA EST to include additional information)

    > set of MASAs that are trusted for enrollment."?

we have added this to section 5.1.

    > throw random extra restrictions into them.

We have determined that section 8.10.3 of the -2018 has the same text.
Neither Max nor I have the official -2018 version, so we are writing:

          Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of
          <xref target="IDevID" /> discusses keyUsage and

Our recommendation continues to be that no EKU be added (consistent
with 1AR, if you have to, then it has to include digitalSignature).

    > number and IDevID.  (Or not, of course.)

I went with 1:1 text.

    > middle of the relevant arrows as well as in the text?

I'm not sure what you mean.
  https://github.com/anima-wg/anima-bootstrap/edit/master/time-sequence-diagram.txt

    > leaves a bad taste in my mouth.

new section added:

 	10.2.  What BRSKI-EST reveals to the registrar

 	   During the provisional phase of the BRSKI-EST connection between the
 	   Pledge and the Registrar, each party reveals it's certificates to
 	   each other.  For the Pledge, this includes the serialNumber
 	   attribute, the MASA URL, and the identity that signed the IDevID
 	   certificate.

 	   TLS 1.2 reveals the certificate identities to on-path observers,
 	   including the Join Proxy.

 	   TLS 1.3 reveals the certificate identities only to the end parties,
 	   but as the connection if provisional, an on-path attacker will see
 	   the certificates.  This includes not just malicious attackers, but
 	   also Registrars which are visible to the Pledge, but which are not
 	   part of the the intended domain.

    > alternative asserts that it can only talk to the proxy over this
    > link-local connectivity, but leaves open the possibility of other
    > avenues of communication (e.g., a WWAN card).

I guess by WWAN card, you mean some kind of LTE or 5G connection?
Or do you mean 802.11/802.15.4?  The distinction matters, because LTE
cards have SIM cards, and therefore are not zero-touch.

    > (The above and below were separate comments; not sure if that came

Oh, I get it.  Added "for the notAfter field"

    >> That's a good question. *** MAX ***

okay, changed text.

    [RFC5280] explains that long lived pledge certificates "SHOULD be
-   assigned the GeneralizedTime value of 99991231235959Z".  Registrars
-   MUST support such lifetimes and SHOULD support ignoring pledge
-   lifetimes if they did not follow the RFC5280 recommendations.
+   assigned the GeneralizedTime value of 99991231235959Z" for the
+   notAfter field.

-   For example, IDevID may have incorrect lifetime of N <= 3 years,
-   rendering replacement pledges from storage useless after N years
-   unless registrars support ignoring such a lifetime.
+   Some deployed IDevID management systems are not compliant with the
+   802.1AR requirement for infinite lifetimes, and put in typical <= 3
+   year certificate lifetimes.  Registrars SHOULD be configurable on a
+   per-manufacturer basis to ignore pledge lifetimes when they did not
+   follow the RFC5280 recommendations.

    > more than just register things.  I get it now, but am not sure how to best

The point of that section is to rule (magic unicorns) out of scope.
It doesn't really matter if we describe the magic correctly, does it? :-)

    > "manufacturer-assigned" is overkill?

We are trying to use the EST terminology here.... how about:

-              an Implicit Trust Anchor database (see <xref target="RFC7030"/>) MUST
+              a manufacturer-assigned Implicit Trust Anchor database (see <xref target="RFC7030"/>) MUST

    > proxy or registrar directly, from somewhere else in the network?  How would

The pledge has made a connection over a Link-Local IPv6 connection.
The Registrar has a connection from a ULA numbered Join Proxy across
the ACP.   That's not a connection across the Internet.  It's true
that neither end can validate what the other end sees.

The Join Proxy could be doing something else: it could punt the connection
elsewhere, or it could channel (in the séance sense) a pledge from some
other place.  If that were occuring, there would indeed be some problem.

Other proposed uses of BRSKI (TEAP-BRSKI) would connect using EAP
over 1x+radius/diameter.

Would some addition to the ACP applicability stating the above
be useful?

    > persistent connections", though?

I'll remove the 1.1.
At the time, we didn't know what HTTP/2 would have.
I think we asked, and were told that HTTP/2 always had persistent
connections, so there was nothing really to say.  I see this as a
statement to some product manager that they really do need to
upgrade their 1998 era HTTP library with something newer.

    > come into consideration during that process could still be useful.

I really think that 5.8.3 says enough.

I have 39 emails in my to-read relating to other DISCUSS.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Aug 2019 12:17:22 -0400

Benjamin Kaduk <[email-masked]> wrote:
    doc> The MASA and the registrars SHOULD be prepared to support TLS client
    doc> certificate authentication and/or HTTP Basic or Digest
    doc> authentication as described in [RFC7030] for EST clients.  This
    doc> connection MAY also have no client authentication at all (Section
    doc> 7.4)

    >> > I don't see discussion of skipping client authentication in Section
    >> 7.4.  > It would be great to have some, there!

    > Oh, the "not verifying ownership" part?  I somehow was interpreting
    > that as "we still require client authentication, but don't have a fancy
    > database mapping owner to hardware, so any authenticated registrar can
    > get a voucher for any device".

There are multiple models on how to operate a MASA.
We think that which one is right depends a lot on the value of the device
(in the ACP space, $100K routers vs $100 CPE devices), and also at the degree
of sales channel integration.
There is value in authenticating the Registrar, even if one does not know
which device has been deployed.  In particular, this model supports the <4h
SLA on service repair that most vendors have, and which they support by
stocking spares in the local city, but not for a specific customer.

I see that I've answered the rest already.
The perils of all these CCs.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Aug 2019 12:28:17 -0400

>> > The audit log is a defense against this in that it allows for
    >> post-facto > discovery of misuse?  Or is there some pre-issuance
    >> authorization check > going on.  > I think I may need some section
    >> references to where the authorization > policy (options) are
    >> documented; I've lost a bit of state on this one.
    >> 
    >> That's right, the audit log provides discovery of mis-use.  The check
    >> belongs prior to issurance of an LDevID, and may be repeated regularly
    >> afterwards.
    >> 
    >> I think you are asking for a list of MASA authorization policy
    >> options.  We do not have such a menu of options, and I'm reluctant to
    >> write them down normatively at this point, as I think that there are
    >> combinations we do not yet understand.
    >> 
    >> Other parts of 5.5 provide other options.  Please let me know if you
    >> think this is insufficient for a Proposed Standard.

    > I think I'd like to see a small addition after/near "[t]his
    > verification is only a consistency check that the unauthenticated
    > domain CA intended the voucher-request signer to be a registrar"
    > (perhaps at the end of the paragraph?) noting something like "since the
    > domain CA is unauthenticated to the MASA, depending on MASA policy,
    > vouchers not authorized by the pledge owner may be issued; the MASA
    > audit log can be used to detect such missisuance".

I've added:

          <t>
            Even when a domain CA is authenticated to the MASA, and there is
            strong sales channel integration to understand who the legitimate
            owner is, the above cmcRC check prevents arbitrary End-Entity
            certificates (such as an LDevID certificate) from
            having vouchers issued against them.
          </t>
          <t>
            Other cases of inappropriate voucher issuance are detected
            by examination of the audit log.
          </t>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Aug 2019 12:58:45 -0400

> (This may not need to be a 2119 MUST since we cite 7030.)

It turns out, in pracice, that many EST clients do not use the CSR
Attributes, so I need this line as a hammer.

    >> > "intended" implies that the EST server has some knowledge of what
    >> the > pledge is expected to be doing in the network, right?
    >> 
    >> Yes.  The ACP document is quite specific about the (rfc822Name)
    >> attributes to assign.  Certainly the attributes could include stuff
    >> like "ve608.core1.tor1.example.net" if the Registrar knew how this
    >> device was to be used, but more likely that would be set up
    >> afterwards.

    > Hmm, maybe later when we say "the local infrastructure (EST server)
    > informs the pledge of the proper fields to include in the generated
    > CSR" we could reiterate that the EST server has local configuration
    > information to inform this messaging, though it's probably not
    > necessary.

I've added the ().

+          fields to include in the generated CSR (such as rfc822Name). 

    doc> To alleviate these operational difficulties, the pledge MUST request
    doc> the EST "CSR Attributes" from the EST server and the EST server
    doc> needs to be able to reply with the attributes necessary for use of
    doc> the certificate in its intended protocols/services.  This approach
    doc> allows for minimal CA integrations and instead the local
    doc> infrastructure (EST server) informs the pledge of the proper fields
    doc> to include in the generated CSR.  This approach is beneficial to
    doc> automated boostrapping in the widest number of environments.
    >> > implies that the validation policy on the CA is somewhat lax, since
    >> the > EST server is expected to be doing most of the policy controls.
    >> Thus, > a compromised pledge/device could send a CSR with unauthorized
    >> fields > and it is likely to be signed, allowing for some level of
    >> privilege > escalation.  When the registrar acts as a proxy to the CA
    >> as well as > its EST role, as described later, this risk is
    >> diminished.
    >> 
    >> I don't really understand.  EST servers are Registration Authorities,
    >> and they have some kind of priviledged access to the CA, and are
    >> mandated to check the CSR.  I expected to find a statement to this
    >> effect in RFC7030, in section 4.2.1, but I don't see any particularly
    >> strong language.  This seems like a quality of implementation issue in
    >> the Registrar.

    > The high-level intended workflow described here is roughly "(1) pledge
    > asks registrar for config; (2) pledge puts that config in a CSR, signs
    > the CSR, and sends the CSR to registrar; (3) registrar passes CSR to CA
    > using registrar's implicit authority.  We don't describe any crypto to
    > check that (2) happens as intended, as opposed to the pledge
    > dishonestly claiming "oh, and I'm a CA" or "I can provide all ACP
    > services, even privileged ones", so that has to be done by policy in
    > the registrar, as you note.  I'm wary of suggesting the workflow that
    > relies on the registrar's implicit authority at the CA without also
    > noting the registrar's policy enforcement obligations.  Though it's
    > possible this is covered elsewhere and doesn't need to be duplicated
    > here.

I think it goes back to the RA and more specifically, the CA, being boss of
what going into a certificate.   To the point where it generally seems really
hard to deploy new extensions in the public WebPKI.

It does say:

          <t>The registrar MUST also confirm that the resulting CSR is formatted as
          indicated before forwarding the request to a CA. If the registrar is
          communicating with the CA using a protocol such as full CMC, which
          provides mechanisms to override the CSR attributes, then these
          mechanisms MAY be used even if the client ignores CSR Attribute
          guidance.</t>

    >> > Section 7
    >> 
    >> > If this is non-normative and will need to be fleshed out in a
    >> separate > document, would an Appendix be more appropriate?
    >> 

    > Er, wouldn't that make this section no longer non-normative?  (Not that
    > I could find the references you're talking about, so a clue bat is
    > welcome.)

It's of the form, "if you wish to do X, then you MUST do Y"
(but, X is not a MUST).

section 9:
   In recognition of this, some mechanisms are presented in
   Section 7.2.  The manufacturer MUST provide at least one of the one-
   touch mechanisms described that permit enrollment to be proceed
   without availability of any manufacturer server (such as the MASA).

    >> > I think this is maybe more of a "does not enforce" than "does not >
    >> know", since the domainID ends up in the audit logs that the MASA >
    >> holds.
    >> 
    >> Yes, but the domainID does not directly identify the Registrar by
    >> name.  Assuming a database breach, what does the MASA know that it can
    >> reveal.

    > domainID is derived from the public part of a certificate, which could
    > well be widely disseminated.  An attacker that compromises the MASA and
    > retains a presence can watch requests come in and backsolve from
    > domainID to certificate directly.

Right, so that's 11.4.3, where the attacker controls the web server.
At which point, they don't need to compromise the database, I think, as they
can just access it.  I think of a database dump as being offline: I get
access to your backups, or I find an SQL injection attack that exfiltrates
data, but does not give me control.

    >> > A nonceless voucher can still include an expiration time ... it is
    >> just > in practice possible for it to never expire, if the target
    >> pledge does > not have an accurate clock.
    >> 
    >> Yes, that's correct.  How many devices with RTCs survive 10 years in a
    >> warehouse with no power? :-)

    > The ones with a radioisotope thermoelectric generator? ;)

So RTCs with RTGs.
Apparently not much plutonium is left for future missions.

    doc> The autonomic control plane that this document provides bootstrap
    doc> for is typically a medium to large Internet Service Provider
    doc> organization, or an equivalent Enterprise that has signficant
    doc> layer-3 router connectivity.  (A network consistenting of primarily
    doc> layer-2

    > (Right, I was saying that you should add it.  But the reworking fixes
    > the nit, so this is all good.)

got it.

    >> It's a good question.  A domain could use a new certificate for each
    >> device, could connect via some onion router.  Is that privacy, or
    >> "semi-plausible deniability"?

    > used/exposed for any other purposes.  So, I don't insist on any
    > specific language, and was just sharing my thoughts about how it is
    > possible to think about this, in case it sparked any insight.

Agreed.
I think that it's hard problem.

    doc> The above situation is to be distinguished from a residential/
    doc> individual person who registers a device from a manufacturer: that
    doc> an enterprise/ISP purchases routing products is hardly worth
    doc> mentioning.  Deviations would, however, be notable.
    >> After buying only Cisco equipment (like ASR 9000) [observed by number
    >> of MASA connections after each POP turn up], ISP example.net suddendly

    > So like "deviations from a historical trend" or "deviations from an

added that text.

    doc> 4.  There is a fourth case, if the manufacturer is providing
    doc> protection against stolen devices.  The manufacturer then has a
    doc> responsability to protect the legitimate owner against fraudulent
    doc> claims that the the equipment was stolen.  Such a claim would cause
    doc> the manufacturer to refuse to issue a new voucher.  Should the
    doc> device go through a deep factory reset (for instance, replacement of
    doc> a damaged main board component, the device would not bootstrap.
    >> 
    >> > I'm not sure I understand this scenario -- is it talking about where
    >> a > third party makes a false theft report in the hopes that the real
    >> owner > will have to do a deep reset and then have the device fail to
    >> bootstrap > because of the reported theft?
    >> 
    >> Yes.

added.

    doc> registrar.  This is mandated anyway because of the operational
    doc> benefits of an informed administrator in cases where the failure is
    doc> indicative of a problem.  The registrar is RECOMMENDED to verify
    doc> MASA
    >> 
    >> > I'd also expect some comment about the limited value of the
    >> additional > information to an attacker in the context where the
    >> attacker already > would know [other information].
    >> 

    > a pledge tries to register using/through but fails.  So that registrar
    > is already in a position where the pledge would try to use it -- in the
    > ACP case, that probably means fairly physically proximate, and maybe
    > implies a link-local connection.

Agreed. In the ACP case, imagine an ISP border router on which there are a number
of links; some of which are internal (legitimate Join Proxy), and some of
which are external links to another ISP's border router (Q).  The Join Proxy
on Q really doesn't know if the purpose of that link has changed from
external to internal.  That's exactly the case of a non-malicious mistake
in finding the right network.

    > In the non-ACP case, maybe it also
    > implies proximity?  I don't know if we can get physical vs. network
    > proximity implied by a pledge trying to use a registrar, but maybe
    > sometimes.  My implied question is basically "what else would an
    > attacker have to do to get a pledge to try to use it as a registrar,
    > and what does the attacker already have access to by the time it gets
    > that far?"  So we can set the information learned from voucher parsing
    > status reports in the context of what else the attacker would already
    > know.  But I don't have the best picture on the deployment scenarios
    > here, so I can't answer the question myself :)

We left the warning there so that the people writing code would think about
this tuscle. My opinion that security paranoia has often gotten in the way of
building debuggable security systems that actually work.  

    doc> this might be an issue during disaster recovery.  This risk can be
    doc> mitigated by Registrars that request and maintain long term copies
    doc> of "nonceless" vouchers.  In that way they are guaranteed to be able
    doc> to bootstrap their devices.
    >> 
    >> > This, of course, comes with a different risk of what is something
    >> like > a long-term credential existing that needs to be protected and
    >> stored.
    >> 
    >> I partially agree.  Long-term nonceless vouchers still pin a specific
    >> domainID.  So they need to available, but they don't need to be
    >> private.

    > It's not entirely clear to me that it's okay to make them totally
    > public (but maybe I am missing something).  That is, in that once the
    > voucher is public, anyone who can get next to the device can
    > re-bootstrap it using that voucher, which possibly gets it into a
    > configuration that's not usable in its current location, and (less
    > likely) maybe it's hard for the real owner to get the correct
    > configuration back (if the original MASA is gone or whatever).  So the
    > voucher is not something I'd want to just put on a public web site.
    > But I guess maybe you don't have to protect it to the same extent that
    > you do your crypto keys.

Not anyone can use the nonceless voucher to bootstrap a device.
If it did, then that would be a bearer voucher ("cash")
It still pins a specific domain CA ("pay $X to Mr. Y").
It's a public document in the same sense that a public key is.

    >> > This gets a bit more complicated to reason about when we assume that
    >> a > pledge will have multiple voucher requests out in parallel,
    >> instead of > doing them in sequence and timing out (so that there is
    >> literally only > one valid nonce at a given time)...
    >> 
    >> Agreed.  But, we think that doing things serially has too much
    >> potential to run into head-of-queue challenges; the risk is that if
    >> devices don't onboard relatively quickly, then BRSKI will get turned
    >> off, not used, or the vendor might provide some "backdoor"

    > reasoning through the risks of the parallel workflow.  How much effort
    > has already been spent doing that reasoning through?  For example, one
    > might want to require that the pledge track which nonce belongs to the
    > voucher request submitted through which candidate registrar, but I
    > didn't work through whether that actually will defend against any
    > attack scenarios.

Each attempt needs to use a distinct nonce.
I thought we said that.  
We say that in section 11, but I've added it to 4.1.

    >> I have dug around cabforum.org and root-servers.org for some
    >> references on what a "well-run secure CA" should be
    >> doing... surprisingly I didn't find an RFC, or one for DNSSEC root
    >> operation. Did I miss them?  I thought that there was one.  I'm
    >> writing some text, and I'll finish this email here, and post the
    >> resulting text.

    > requirements (https://cabforum.org/baseline-requirements-documents/)
    > but never actually looked. :-/ We could ask around if it's important
    > (but I don't think there's an RFC).

I will save it for an operational document.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Aug 2019 13:02:45 -0400

> (That is, if the boxes are already in local storage at the time of
    > first compromise)

yes. If you have physical care of them, then nobody could have tried an
attack while the MASA signing key was compromised.

    >> case because the operator controls the communication between Registrar
    >> and MASA, and there is no opportunity to introduce the fake voucher
    >> through that conduit.

    > This seems predicated on the attacker having the MASA signing key but
    > not persistent control of the (formerly?) legitimate MASA service,
    > right?

yes, that's right.  Assume the key was generated in a deterministic way
(the way the SSH keys were), or brute-forced, or something like that.

    >> short-lived vouchers.  That key needs significantly better protection.
    >> If both keys come from a common trust-anchor (the manufacturer's CA),
    >> then a compromise of the manufacturer's CA would be a bigger problem.

    > (probably some wordsmithing options for "be a bigger problem")

how about:
              If both keys come from a common trust-anchor
              (the manufacturer's CA), then a compromise of the
              manufacturer's CA would compromise both keys.  Such a
              compromise of the manufacturer's CA likely compromises
              all keys outlined in this section.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Aug 2019 12:07:40 -0500

> attack while the MASA signing key was compromised.

I guess that makes the "under physical control of the owner" the relevant
property, so emphasizing that in the text might be good.

> (the way the SSH keys were), or brute-forced, or something like that.

I was initiall confused about this, so it might be worth adding some text.
(But then again, sometimes I'm easily confused...)

>               all keys outlined in this section.

WFM.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Aug 2019 18:30:30 -0500

>             integration, then the identities are not pseudonymous.

Thanks!

> MASA EST to include additional information)

I agree that we don't need to talk about all the different ways by which a
previously unknown manufacturer could become trusted.  Mostly just the word
"secure" caught me up.

> with 1AR, if you have to, then it has to include digitalSignature).

Definitely!

>   https://github.com/anima-wg/anima-bootstrap/edit/master/time-sequence-diagram.txt

Proof of concept in https://github.com/anima-wg/anima-bootstrap/pull/135 .
Feel free to say it doesn't make sense :)

>  	   part of the the intended domain.

Thanks.

> cards have SIM cards, and therefore are not zero-touch.

Um.  I think I meant LTE, along the lines of how I can buy a car these days
that will "phone home" to the dealer when I need to go in for service.

> +   follow the RFC5280 recommendations.

Ah, that is much clearer to me; thanks.

> It doesn't really matter if we describe the magic correctly, does it? :-)

I don't think we have an IETF spec for unicorns, no.  Maybe there's an ISO
standard unicorn?

> +              a manufacturer-assigned Implicit Trust Anchor database (see <xref target="RFC7030"/>) MUST

That works for me.  And, honestly, leaving it as-is would be okay.

> Would some addition to the ACP applicability stating the above

Oh sure, the link-local IPv6 of the proto-ACP would be a great way to show
locality.  Please do add some text regarding the ACP applicability.

> I really think that 5.8.3 says enough.

It probably does (and we should feel free to forward-reference it from
here).

> I have 39 emails in my to-read relating to other DISCUSS.

Oh my; keep up the good work!  But do take breaks periodically...

Thanks,

Ben

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Aug 2019 20:06:56 -0400

Hi,

I have pushed -26 to the datatracker.

I believe that this addresses all IESG comments received, as well as the 
comments from Christian's second review.  In particular, I added a paragraph
to the intro as he suggested, as well as adding section 7.4.3, which is
now referenced by section 10.6 ("meddling").

As previously indicated, when I fixed the wrap issue in the examples between
-23 and -24, this resulted in a very unreadably wide diff.  I posted -23 as
having only that fix, so compare -26 to -24 if you want to see everything
since your review.
Here is a link to help:
   https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-23&url2=draft-ietf-anima-bootstrapping-keyinfra-26

The new text is pending proof-reading by myself and others, but as you may
know, it is impossible to catch small errors in this text.

Will Randy be happy? I hope so :-)

This is has been a very long effort for me and my co-authors, about 75 hours
of effort, occupying most of my brain for a month.  If substantive are
still needed, they won't occur until mid-September.

There is still perhaps the somewhat "minor" issue of whether we should have a
registry created for the /.well-known/est. It feels like overkill to me.
I'm not sure if my instructions clearly say to add "see also " to the related
information. I reviewed some of the documents referenced under "related information",
and I did not see any instructions in them.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Aug 2019 20:16:16 -0400

Benjamin Kaduk <[email-masked]> wrote:
    >> I guess by WWAN card, you mean some kind of LTE or 5G connection?  Or
    >> do you mean 802.11/802.15.4?  The distinction matters, because LTE

    > Um.  I think I meant LTE, along the lines of how I can buy a car these
    > days that will "phone home" to the dealer when I need to go in for
    > service.

And which is never actually your car, nor has it any actual credentials
that you control :-)

It was onboarded at the factory.

    >> Would some addition to the ACP applicability stating the above be
    >> useful?

    > Oh sure, the link-local IPv6 of the proto-ACP would be a great way to
    > show locality.  Please do add some text regarding the ACP
    > applicability.

Added after -26.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Aug 2019 12:39:57 -0500

> stocking spares in the local city, but not for a specific customer.

Understood.  To be clear, this was only ever intended to be an editorial
question (to be more explicit about not using client authentication), so
... use your editorial discretion.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Aug 2019 17:33:16 -0500

> Attributes, so I need this line as a hammer.

Fair enough.

>           mechanisms MAY be used even if the client ignores CSR Attribute

Hmm, I guess I must have missed that or skimmed over it too quickly.

> It's of the form, "if you wish to do X, then you MUST do Y"

That specific construction would seem like an "optional feature" per
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
...

>    without availability of any manufacturer server (such as the MASA).

... but this is a somewhat different construction.  In isolation, it looks
more like "MUST do at least one of X, Y, Z" without condition on "wish to
do W", and if X, Y, and Z are all in the same place, that place seems
normative to me.  (I will confess I've rather lost track of exactly why
we're debating if this is normative or not; I guess it's just the
disclaimer in Section 7 about "considered non-normative in the generality
of the protocol".)

> Right, so that's 11.4.3, where the attacker controls the web server.

The "watch requests come in" is, yes.  But if we don't constrain the
visibility/use of the certificates in question, they could be out "in the
wild" and thus correlatable even with just a database dump/snapshot.

> It's a public document in the same sense that a public key is.

IIUC I don'to have to prove possession of the private key corresponding to
a certificate that chains to that domain's CA in order to get the pledge to
accept the voucher.  That is, even if I can't get the device to work for
me, I can still keep someone else from using it (e.g., reusing a nonceless
voucher for the original owner after re-sale).

> Each attempt needs to use a distinct nonce.

That's true, but not quite what I was looking for.  With two outstanding
nonces, now I have to keep track of which nonce went where and use the
right nonce to attempt to verify a response.  I also have to consider the
case where I send out two requests and get back two valid responses.
Presumably I take whichever one shows up first and validates, but are there
risks associated with rejecting the other one or not knowing whether it was
valid?  If I use predictable nonces, could that allow another party to
affect the outcome of the "race" between which response shows up first?

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Sun, 18 Aug 2019 16:09:50 -0400

> https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/

I re-read this, and this as to do with References, and so anything optional
referenced in section 7 would still need to be a Normative Reference.

The stickler I see right now is [I-D.ietf-netconf-keystore].
I don't want to hang on MISREF on that document; it's just one of many that
could be used, and I do not want to tell manufacturers that they have
to use this specific protocol to update trust anchors.
There are many other protocols that they presently support which they could
use, in particular, a CLI interface would be fine.

I think that this 7.4.3 section that creates a factory default which isn't
the default from the factory should be worry people who care about remote
attestation of software.

Adam has been particularly vocal about the need to specify something
normative that manufacturers have to provide in order to resale and operation
with the availability of the MASA.

It seems that we might need another round of discussion on this topic.
I feel that we are being pushed to describe the entire security lifetime of
the device; that we need to solve the entire management problem of devices in
our document.  (i.e. the 25 years of SNMPv3, plus YANG...) Maybe I just don't
understand what would be a reasonable answer, if what I've written is not enough.

Maybe a virtual interim discussion!   If so, please let me know.
ANIMA/Iot-Onboarding has some time booked already:
    https://datatracker.ietf.org/meeting/interim-2019-anima-01/materials/agenda-interim-2019-anima-01-anima-01

ps: (s/IPv6 NAT44/IPv4 NAT44/ for section 7.4.2, btw)

    > disclaimer in Section 7 about "considered non-normative in the generality

Yes, it's MUST do one of X,Y,Z.
So that implies: MAY do X, MAY do Y, MAY do Z, but not the case of all being false.