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

[Alissa Cooper <[e-mail]>]

> On Jul 10, 2019, at 10:56 PM, Michael Richardson <[e-mail]> 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.

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

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

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