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

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 10 Jul 2019 13:42:30 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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 out of
business before the device is enrolled, the ability for the device to function
securely on the network may be significantly impaired if not impossible. It
seems like this document needs to make clear to manufacturers that a fallback
manual enrollment mechanism of some sort needs to be implemented along with
BRSKI in order to avoid this situation.

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

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

= Section 2.3.1 =

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

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

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jul 2019 22:56:26 -0400

Alissa Cooper via Datatracker <[email-masked]> wrote:
    > 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)

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

    > and (2) what is operationally required of a domain owner to support

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.

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

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

    > 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jul 2019 16:46:28 +1200

> except that you get a serial-console)

Alissa, I've been concerned about this aspect since the -00 draft,
especially for the case of air-gap deployments where the MASA is in
any case inaccessible. I think it is indeed covered by section 7, which
also mentions the need for future work. But it seems better to document
the basic mechanism first.

> in a TPM module, then enrollment can be done securely.

The same applies to equipment in street cabinets or shared premises, which
might be physically accessible to bad actors (or untrustworthy employees).

    Brian

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 11 Jul 2019 09:45:55 -0400

> On Jul 10, 2019, at 10:56 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

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.

> 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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 11 Jul 2019 16:33:19 +0200

Alissa,

This is not a BRSKI specific issue/question. This is a question that
equally applies to system design across pledge/client, server/registrar
and masa when using Netconf Zerotouch (RFC8572). Or any
other protocol relying on the RFC8366 voucher security architecture.

In fact, BRSKI already answers a lot more system design issues in
section 7 than RFC8572 does and RFC8572 did (appropriately) make it through
to RFC without these system design options being elaborated on in that RFC.

I consider all the system design aspects already covered in BRSKI to
be somewhat opportunistic by now. In hindsight we could have a much shorter
BRSKI protocol spec and a more comprehensive voucher architecture
document applicable to netconf/BRSKI and other protocols (that leverage
vouchers), but we didn't knew this when we started, and then it was too late.
And of course WG reviewers kep hammering to answer questions ;-)

So, to the extend that authors have not already spent cycles to write
up things in BRSKI that really are not specific to BRSKI (such as section 7),
i would appreciate if we would put put generic voucher security architecture
option discussions into followup work written in a way that its
understood how to apply to BRSKI, Netconf and any other (future) protocols.

Btw: 

Primarily, as a customer i do not worry about the problem, because i want to use
BRSKI to AVOID having to buy and store equipment. The typical use case
is to do just-in-time-order of equipment shipped to insecure deployment
location. If at all, its an issue of the reseller if the reseller wants to buy
bulk, store and sell potentially years later. Something no sane reseller
does these days with electronics equipment that quickly deteriorates in
value. 

Now, when i need to (factory) reset a device years later i might run into the
issue, and there are various solutions, but the best way for IETF to
deal with this would be to have appropriate trust storage YANG models
that express behaviour for such system reset or other operational device
procedures.

> the ISP, what part would be the "hostile environment"?

https://media04.kreiszeitung-wochenblatt.de/article/2017/10/24/8/277508_L.jpg?1554098709

(obviously BRSKI doesn't help against the explosives, that part of the
 picture is just for fun, but there are more subtle physical attack vectors
 against these physcially badly secured locations where BRSKI helps. And
 beside ATMs there are a lot more even less well protected retail
 locations with small routers in them connecting to corporate networks).

I'll not answer to your discuss individually (leave it to the authors),
but would like to mention that a coupe of your asks also relate to the
"not BRSKI specific" or "better for a "BRSKI operations" document than
further bloating the protocol spec.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 11 Jul 2019 17:08:19 +0200

On Thu, Jul 11, 2019 at 09:45:55AM -0400, Alissa Cooper wrote:
> 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.

> 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

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 13:16:00 -0400

Toerless Eckert <[email-masked]> wrote:
    >> 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* ?)

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

It seems to me that this belongs at the end of 1.0, just prior to 1.1?