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

[Toerless Eckert <[e-mail]>]

On Thu, Jul 11, 2019 at 09:45:55AM -0400, Alissa Cooper wrote:
> > 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.
> 
> Yes, but section 7 is non-normative (maybe? per Roman???s DISCUSS). So is the conclusion a reader is supposed to draw that it???s ok for manufacturers to ship devices with BRSKI as the exclusive onboarding mechanism? The fact that this may already happen today with other protocols doesn???t seem like a reason to perpetuate it.

There are many different answers to that question for many different use
cases. Thats not really a BRSKI question. Heck, i could have a device
with BRSKI and Netconf zero-touch and voucher-via-USB stick, but no open
console, so i have three "protocol" enrollment options, but they will all
have the voucher as a single point of failure and i can easily come up with
a use case where this is desired by the customer.

> > 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.
> 
> So a consumer user???s home network, including the user???s CPE, is considered to be part of the ISP???s ???professionally managed??? network?

Pretty standard use case that CPE is provided/managed by the SP.
Traditionally you got a routing CPE that you couldn't touch as
the customer and the non-professional managed network started on the
LAN ethernet ports of that CPE. Nowadays CPEs for more bitchy home
customers have the SP boundary inside the software of the router,
locking down all the WAN-side config and anything else the SP wants
to lock down. Only some countries regulations force SPs to provide
more liberal access, but whenever the CPE is fully provisioned by the
customer alone, the support by the SP is often reduced.

Again, 1001 use cases. In countries where there is a strong retail
router market and end-users choose and deploy their router independent
of the SP, BRSKI is still equally valuable, but now it would be the
vendor of the retail router who would offer BRSKI/MASA and a customer
web-portal to automate secure, automated deployment.

> And if the consumer needs to fallback to some non-BRSKI mechanism he is expected to bootstrap the device via serial console himself? Trying to see if I understand the scope limitations explained in Section 9.

Non-BRSKI operators have to prequalify by showing their
knowledge of serial port console operations and morse code. 
(do i have to say *kidding* ?)

How about:

The zero-touch mechanism presented in this and the ACP document
represents a signficiant efficiency: it avoids the need to ship devices
to secure locations to provision them before deployment or to ship senior
experts to remote and often insecure deployment locations to provision
devices on-site with mechanisms as antiquated as craft serial consoles. 

Cheers
    Toerless

> 
> Thanks,
> Alissa
> 
> > 
> >> ----------------------------------------------------------------------
> >> 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 =-

-- 
---
[e-mail]