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

[Michael Richardson <[e-mail]>]

Benjamin Kaduk <[e-mail]> 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.
    >> 
    >> > 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?

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

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

    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.

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

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.

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

    > nit: duplicated "value from the"

fixed.

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

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

    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.

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

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.

    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.

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

    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

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

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.

    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.

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

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

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