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

[Michael Richardson <[e-mail]>]

Alissa Cooper via Datatracker <[e-mail]> wrote:
    > I apologize if I'm misunderstanding how this works, but I didn't see much
    > discussion in the document about the implications of the manufacturer going out
    > of business. Specifically, it seems like if a device ships with BRSKI as its
    > only available mechanism for bootstrapping and the manufacturer goes

Section 7 provides some detail on a number of mechanisms that a manufacturer
could chose to include that would permit a device to be onboarded with
reduces levels of trust.
Section 7.2 specifically mentions onboarding via serial-console.

(This situation is really no different from buying an iPhone 4 and then
complaining that you can't make it work because Apple won't give you
software that is secure, and since it's insecure, they won't onboard you,
except that you get a serial-console)

    > = Section 1.3.1 =

    > "But this solution is not exclusive to large equipment: it is intended
    > to scale to thousands of devices located in hostile environments,
    > such as ISP provided CPE devices which are drop-shipped to the end
    > user."

    > I don't quite understand how this squares with the scope limitation described
    > in Section 1 and Section 9. If the whole network is professionally managed by
    > the ISP, what part would be the "hostile environment"?

The thousands of CPE devices (cable modems, VDSL modems, ISP provided home
routers) can be taken apart by the home owner.  If such devices have IDevID
in a TPM module, then enrollment can be done securely.

    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------

    > I think this document would benefit from two concise lists, with notes about
    > which items in each list are defined in this document and which ones are not
    > defined: (1) what is operationally required of a manufacturer to support BRSKI,
    > and (2) what is operationally required of a domain owner to support
    > BRSKI.

We did start this document describing the protocol from the point of view of
each party (Pledge, Proxy, Registrar and MASA).  This would be the way that
each instrument in an orchestra receives their music.

We found that readers found it very difficult to understand the big picture,
so we now describe the protocol in time-sequence, the way that the script for
a play would be described.

But, you are asking for Operational requirements, not protocol requirements.
I agree that this would be useful, and it's something that I'd like to write.
I would consider it more of a BCP, and I don't think we have the experience
to write this down yet.

    > = Section 2.3.1 =

    > What precisely is meant by "TPM identification"? Could a citation be provided?

I don't have a reference, I hope Max can provide one.
I imagine it would point to a TCG document.

It's a SubjectAltName extension that is in a TPM contained certificate that
tells relying parties what TPM device it is.

    > = Section 10.1 =

    > "The domain can maintain some privacy since it has not necessarily been
    > authenticated and is not authoritatively bound to the supply chain."

    > What does this mean? That the domain can expect the manufacturer not to trust
    > the domainID because it hasn't been authenticated?

The MASA has a list of devices, and for each device, it has a list of current
and previous owners.  This is the audit log.  The MASA will disclose this to
current and previous owners, if they can present a voucher-request that was
From the device.   (section 5.8)

It's hard to understand what kind of attack there is, but imagine that xyz.example.net
goes under, sells a huge stack of example.com 48-port 100G BFRs to other
ISPs.  (The manufacturer, example.com is still alive and well, and is happy
to take 10% support contracts from 30 new customers as it authorizes the
resale)

Someone gets the Registrar database from xyz.  They can now discover who
ownes all these BFRs... and(?)...profit.
Perhaps this needs to be coordinated with resale of some other device.
That can be done as, although the audit log does not list the actual
customer, it lists them by SHA-1 hash of public key.

So the sentence above notes that it's not like the Registrar told the
manufacturer who it was, if it didn't authenticate.  As such, either
xyz.example.net or the new owners could generate a new domainID, and
register each device uniquely.
(They want to use some kind of ONION routing to obfuscate their IP address
too, but that's instantly defeated if they authenticate with TLS 1.2
using a ClientCertificate)

I'm sure that we could improve this examplanation, but I'm not exactly sure
how yet.

    > = Section 10.2 =

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

    > What does the last sentence mean?

A residential ISP that buys 10,000 Linksys CPE routers is unremarkable.
When the same ISP buys 10,000 Internet connectable sex toys as well, that
might represent some kind of change in business plans.
Would a PC vendor be interested if some Enterprise customer suddenly bought
only tablets?

The BRSKI-MASA connection does not reveal what is bought, but it does reveal
who is doing business with whom, and it may also reveal volume.  This is
just traffic analysis. Christian Hopps has a nice document on defeating that, btw.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-