Subject: Re: [Anima] Ownership Concept

From: Robert Cragie <[email-masked]>
Date: Wed, 01 Apr 2015 11:10:13 +0100

Hi Max,

Thanks for your responses. Further responses inline, bracketed by 
<RCC2></RCC2>

Robert

On 30/03/2015 18:03, Max Pritikin (pritikin) wrote:
>>
>>
>>>     There are certainly cases where I can see this being used but
>>>     conceptually it is not much different to a whitelist on the
>>>     registrar.
>>
>>     The registrar is owned and operated by the domain owner. The
>>     cloud service is not. I argue MASA substantially simplifies the
>>     threat model.
>>
>>
>> <RCC>I see now that the purpose of the MASA service is not online 
>> whitelisting, and the difference in the domain authority and the 
>> MASA.</RCC>
>>
>>
>>>     The only other operation it seems to do is to sign the domain
>>>     certificate. But the registrar could also do this - so I guess
>>>     this is really combining MASA and registrar in a single box.
>>>     Either way, the NE has to have the domain public key, whether
>>>     the MASA or the Registrar is authorised to issue domain
>>>     certificates on behalf of the Domain CA and any other public
>>>     keys relevant to the certificate chain.
>>
>>     The MASA does not sign certs
>>
>>
>> <RCC>So why is it called a "signing authority" then? Confusing. I can 
>> see it may sign authorisation tokes (see later).
>
> Understood. It signs the “proof of logging” things we called 
> “authorization tokens”. Please feel free to suggest terms that resonate.
<RCC2>I think "authorization token" is fine. There needs to be more 
detail on the process, that's all.</RCC2>
>> <RCC>
>> So please explain the authorisation token in more detail and what 
>> leads to its generation. This is a bit more than just logging.
>
> s4.1.2: NE only joins a domain if an authorization token is provided. 
> This behavior of the NE ensures that a log of the authorization token 
> is also a log of every time the NE joins a domain.
<RCC2>OK</RCC2>
>
> s4.3.2: Registrar only allows the device to join the domain if the 
> devices history (e.g. the log information) doesn’t show it has joined 
> Mallory’s domain. Or, if the registar doesn’t care, maybe it just 
> doesn’t check.
<RCC2>I would imagine Mallory's purpose is to manipulate the joining to 
make it look as if the NE didn't join Mallory's domain. I see that the 
MASA check is auxiliary and optional</RCC2>
>
> s4.3.3: Registrar MUST claim the device, obtaining an authorization 
> token and ensuring a log entry is generated, in order to get the 
> device to trust it.
<RCC2>OK</RCC2>
>
>> As far as I can see (and please correct me if I am wrong), the 
>> Mallory/honeypot detection isn't really shown in Figure 1.
>
> In figure1 note that “device history log” and “authorization token” 
> are sent to the Domain from the MASA. The Domain then decides “still 
> accept device?” based on the log information. This is the Registrar 
> checking for Mallory. If the log information shows an 
> unknown/unexpected log entry then Mallory has been detected.
>
> It is still the Domain’s policy decision about continuing.
>
>> For this to work, the NE would have to send details of the registrar 
>> it has received, presumably relayed by the registrar itself (OCSP)?
>
> Ummm… didn’t follow you completely. I suggest keeping the log 
> information in the cloud and delivering it to the registrar from there 
> because I don’t trust the NE to reveal that it is has been corrupted 
> by Mallory.
<RCC2>I think what is missing is that the request needs to come from the 
NE and contain information about the Domain the NE thinks it is 
connecting to as well as the NE. Otherwise Mallory could successfully 
act as MITM and convince the NE that it is a legitimate domain. See 
attached diagrams.</RCC2>
>> Then the MASA service sends a signed authorisation token back, 
>> attesting the validity of the Registrar. A honeypot would not be able 
>> to provide valid credentials so at that point would fail.
>
> Correct, the Mallory domain would have to contact the MASA to obtain a 
> signed authorization token which ensures that the event has been logged.
>
>> If a honeypot tried to use a honeypot MASA, it wouldn't have the 
>> private key to sign the authorisation token so that would fail to. If 
>> the honeypot claims the MASA is unreachable - another failure. So I 
>> agree, a good way to simplify the threat model.
>> </RCC>
>>
>>
>>>     Regarding the honeypot (Mallory) attack - the NE is going to
>>>     find out it's a honeypot as the honeypot will not be able to
>>>     issue valid domain certificates.
>>
>>     The NE can't identify a "valid" domain certificate so I don't
>>     believe this is correct.
>>
>>
>> <RCC>It could if it were pre-provisioned with the Registrar's public 
>> key and Domain CA public key. As you point out, in Section 2, "As a 
>> service offering the MASA can incorporate many of the bootstrapping 
>> elements (such as the Registrar and the Domain CA) into the overall 
>> service." So surely in this case, there is no separation of CAs?</RCC>
>
> For any given domain one could do this. But it doesn’t work at scale 
> or if the target domain isn’t known when the device leaves the vendor.
<RCC2>All the more reason for the additional data needed at the 
beginning of the sequence (Domain ID sent to NE)</RCC2>

Robert

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Thu, 9 Apr 2015 03:06:24 +0000

Hi Max,
Please see my comments inline.

  >-----Original Message-----
  >From: Robert Cragie [mailto:[email-masked]]
  >Sent: Wednesday, April 01, 2015 6:10 PM
  >To: Max Pritikin (pritikin)
  >Cc: Hedanping (Ana); Michael Richardson; [email-masked]
  >Subject: Re: [Anima] Ownership Concept
  >
  >Hi Max,
  >
  >For any given domain one could do this. But it doesn't work at scale or if the
  >target domain isn't known when the device leaves the vendor.
  ><RCC2>All the more reason for the additional data needed at the beginning of
  >the sequence (Domain ID sent to NE)</RCC2>

Agree, my understanding from the draft is that 'Registrar is informed a priori the unique identifier (e.g. serial number)... ',  the vendor should already know the domain/registrar before the device leaves, and the registrar is informed of the device list. If that's the case, why not pre-configure the device with the domain ID/ registrar ID or certificates? 
Besides, if the NE is moved from one domain to another, necessary configuration should be done to the NE and corresponding registrars should be informed, and the registrar must trust such configuration. Therefore MASA's log information is not important to the registrar/the joining NE and may not be part of the bootstrapping messages.

Ana

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Apr 2015 17:51:53 +1200

Hi Ana,
On 09/04/2015 15:06, Hedanping (Ana) wrote:
> Agree, my understanding from the draft is that 'Registrar is informed a priori the unique identifier (e.g. serial number)... ',  the vendor should already know the domain/registrar before the device leaves, 

I don't think that is realistic. The device could be sold to a dealer by
the manufacturer, sit in the dealer's warehouse for a year, and then be
sold by mail order to a PO Box address in another country. In a managed
network you can assume that the device identity is made known to the
registrar before it is connected to the the network, but there will be
many cases where there is no prior communication of any kind between
the registrar and the manufacturer. In an unmanaged network there is
also no pre-registration at all.

   Brian

> and the registrar is informed of the device list. If that's the case, why not pre-configure the device with the domain ID/ registrar ID or certificates? 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 9 Apr 2015 19:04:31 +0000

On Apr 8, 2015, at 9:06 PM, Hedanping (Ana) <[email-masked]> wrote:

> Agree, my understanding from the draft is that 'Registrar is informed a priori the unique identifier (e.g. serial number)... ‘,

Noting that this is just a list of product serial numbers, such as from an electronic bill-of-sale or read from packaging material using a bar code reader or whatever. 

>  the vendor should already know the domain/registrar before the device leaves, and the registrar is informed of the device list. If that's the case, why not pre-configure the device with the domain ID/ registrar ID or certificates? 

I agree with Brian that this is difficult with complex modern supply chains. Tracking “the device to domain association” requires the domain and vendor to have a secure and authenticated channel but also your suggestion requires that this information is known before the device enters the supply chain at all. As Brian points out this impacts any warehouse or resale mechanism. 

> Besides, if the NE is moved from one domain to another, necessary configuration should be done to the NE and corresponding registrars should be informed, and the registrar must trust such configura…

In order for domain_1 to do the "necessary configuration” it must be trusted by the NE, which means that the association was logged at the vendor’s MASA server. Lets assume that either the NE was wiped to factory defaults OR that domain_1 installed malware - either of which could be used to (re)trigger bootstrapping when the NE joins domain_2. During bootstrapping the domain_2 registrar contacts the MASA server as per normal bootstrapping operations. The log information is analyzed and if domain_1 was expected, perhaps as a normal part of the vendor’s potentially complex supply chain or because domain_2 knew it was purchasing used equipment, then bootstrapping proceeds as normal. On the other hand, if domain_2 normally never sees logs with domain_1 in them then this triggers an exception and the domain_2 registrar is afforded the opportunity to involve the administrator, apply additional configuration validation, or whatever. 

The vendor’s responsibilities never are not effected. Although the vendor has interesting information about how many times the NE has (re)trigger bootstrapping it doesn’t necessarily even know the actual identity of domain_1 or domain_2. 

- max

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2015 08:29:40 +1200

Just one extra point below to make myself a bit clearer:

> I agree with Brian that this is difficult with complex modern supply chains. Tracking “the device to domain association” requires the domain and vendor to have a secure and authenticated channel bu…

Right. But I would like to be clear that I don't regard a MASA as the only
solution to this problem. Another solution is some kind of check-in
procedure: when a device is purchased by a network operator*, they perform
an in-house procedure that does a factory reset for safety, then generates
a new key pair inside the device, and then securely registers the new public
key and the device identity. That means that the manufacturer, the supply
chain, and the MASA all disappear from the trust model.

* "operator" could include a home user, with a simple registration
process in the Bluetooth style.

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 9 Apr 2015 21:32:57 +0000

On Apr 9, 2015, at 2:29 PM, Brian E Carpenter <[email-masked]> wrote:

> solution to this problem.

My responses are in terms of the bootstrapping draft so I refer to MASA. Alternative cloud based mechanisms have differing tradeoffs as we’ve been discussing. 

> Another solution is some kind of check-in

I agree that “touch based” models also exist. 

The difficulty is of course proving physical possession. Bluetooth and similar models usually fall back on “unauthenticated” connections when necessary input/output functionality aren’t available on the devices. I tend to discount these due to the security characteristics but appreciate your keeping them part of the conversation. 

> process in the Bluetooth style.

My thinking on this is that we want to enable that same user to have a similar user experience but *also* provide the more discerning and security aware administrator the ability to implement a better security model without forcing them to chose different pieces of hardware or run different software paths.

- max

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Apr 2015 17:57:05 -0400

Max wrote in response to a thread from Ana:
    >> I agree with Brian that this is difficult with complex modern supply
    >> chains. Tracking “the device to domain association” requires the
    >> domain and vendor to have a secure and authenticated channel but also
    >> your suggestion requires that this information is known before the
    >> device enters the supply chain at all. As Brian points out this
    >> impacts any warehouse or resale mechanism.

Brian E Carpenter <[email-masked]> wrote:
    > Right. But I would like to be clear that I don't regard a MASA as the
    > only solution to this problem. Another solution is some kind of
    > check-in procedure: when a device is purchased by a network operator*,
    > they perform an in-house procedure that does a factory reset for
    > safety, then generates a new key pair inside the device, and then
    > securely registers the new public key and the device identity. That
    > means that the manufacturer, the supply chain, and the MASA all
    > disappear from the trust model.

Just for further clarity,
1) to whom do they register the new public key?
2) do they remove any other vendor key?
(802.1AR offers both keeping the IDevID and adding a LDevID, and also
the option to replace the IDevID)

I believe with judicious use of things like QR codes on the packaging
containing either symmetric authentication secrets, (or possibly even
assymmetric private keys), that one can bypass a number of layers of
unevolved supply chain.

My proposal would be to start from the premise that the supply chain has
evolved already, and figure out how we bootstrap in that situation, and then
we add way to mitigate the unevenness of new technology.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 9 Apr 2015 23:05:39 +0000

> we add way to mitigate the unevenness of new technology.

This is an excellent point. Being able to incrementally add functionality to an existing supply chain without having to upgrade the entire supply chain is an important consideration. 

- max

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2015 11:51:06 +1200

> 1) to whom do they register the new public key?

Their own CA, within their own network. Remember that our target
market for Anima includes very large networks (carriers or large
enterprises).  But that isn't the whole market, of course. Smaller
enterprises may be happier to farm out security functions to the
cloud, although it will only take one well-publicised breach for
that to become less popular.

I think we have to design the base mechanisms to be very tolerant
of multiple scenarios.

> the option to replace the IDevID)

Good question. At first sight I don't see a good reason to destroy
existing keys.

> we add way to mitigate the unevenness of new technology.

I don't see coping with various scenarios as mitigation, but as a basic
requirement. For one thing, even if the supply chain evolves in a certain
way, it will continue to evolve in the long term, and we want to avoid
a legacy problem when that happens.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Apr 2015 11:55:12 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> would like to be clear that I don't regard a MASA as the > only
    >> solution to this problem. Another solution is some kind of > check-in
    >> procedure: when a device is purchased by a network operator*, > they
    >> perform an in-house procedure that does a factory reset for > safety,
    >> then generates a new key pair inside the device, and then > securely
    >> registers the new public key and the device identity. That > means
    >> that the manufacturer, the supply chain, and the MASA all > disappear
    >> from the trust model.

    >> Just for further clarity, 1) to whom do they register the new public
    >> key?

    > Their own CA, within their own network. Remember that our target market
    > for Anima includes very large networks (carriers or large enterprises).
    > But that isn't the whole market, of course. Smaller enterprises may be
    > happier to farm out security functions to the cloud, although it will
    > only take one well-publicised breach for that to become less popular.

I don't mean to be obtuse, but do I understand the process you are describing
to be:
  1) the network operator unboxes the system in a lab/provisioning center
     (It sure sounds like a serial console. I have learnt recently, this is
     called the "craft terminal" in telco speak.  On small devices, this
     cable might speak USB or JTAG...)

  2) the network generates the new key, and enrolls it, I guess doing a
     copy and past on the craft terminal of the certificate request.

  3) the network operator boxes the system backup and ships it to where it
     needs to go. (which might be a warehouse, where it will wait as a spare part)

    >> 2) do they remove any other vendor key?  (802.1AR offers both keeping
    >> the IDevID and adding a LDevID, and also the option to replace the
    >> IDevID)

    > Good question. At first sight I don't see a good reason to destroy

If you leave the original IDevID there, and it is possible to reset the
device into a state where it will use that ID, then it is possible that the
original vendor can now "steal" the device back by issuing a new ownership
token.

    >> My proposal would be to start from the premise that the supply chain
    >> has evolved already, and figure out how we bootstrap in that
    >> situation, and then we add way to mitigate the unevenness of new
    >> technology.

    > requirement. For one thing, even if the supply chain evolves in a
    > certain way, it will continue to evolve in the long term, and we want
    > to avoid a legacy problem when that happens.

Okay, if you don't like the word "mitigation", I'm okay with that.
My intention is that we create an endgame scenario and then we add some
transition strategies that can disappear later on.  (I realize how poorly
this has gone with IPv6, so let's not go down that rathole, unless you
fundamentally disagree with this strategy)

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 10 Apr 2015 16:26:05 +0000

Michael, some questions for you inline so I can better understand the issues you’re thinking about, 

On Apr 10, 2015, at 9:55 AM, Michael Richardson <[email-masked]> wrote:

>     cable might speak USB or JTAG…)

This describes a relatively high touch scenario where the device is staged and supports the so called “craft terminal” as an out-of-band management channel. This incurs additional operational (staging) and capital (extra interfaces) expenses so I tend to think in terms of non-staging and inline solutions (aka “zero touch” etc). Do you have a sense that the model you’re describing here will become more widespread?  

>     copy and past on the craft terminal of the certificate request.

Even if we assume a “craft terminal” that is physically secured do you think it is a good idea to have the network generate the key — or do you see value in the more classic asymmetric key approach where the device generates the key itself if possible?

>     needs to go. (which might be a warehouse, where it will wait as a spare part)

Do you imagine that the credentials installed in 1-2 are the final credentials for the device? Or do you think it might have more generic credentials while it sits in the warehouse and be issued its final credentials after it is deployed? 

Do you see value in the device manufacturer providing steps 1-2 during manufacturing thus saving the final customer the costs and complexities of these steps? 

> original vendor can now "steal" the device back by issuing a new ownership

Please keep in mind here that the IDevID credential is the devices identity. The concern you are raising is around the device having a Trust Anchor of the vendor. Verification of a provisioning "authorization token” is one way this Trust Anchor might be used. Another way it is often used is verification of code updates from the vendor. Are you proposing that the new owner of the device be capable of removing this Trust Anchor? If so how do they perform secure software updates?

If the IDevID credential is permanently removed then the device’s behavior has been permanently changed. If the IDevID credential is *only* used for authenticating the device during an initial provisioning/bootstrap then removing it means the device can never be provisioned again w/o depending on the “craft terminal” concepts above. What does one do to secure (re)provisioning of a wireless only device in your model? 

Thanks,

- max

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Apr 2015 15:12:47 -0400

Max Pritikin (pritikin) <[email-masked]> wrote:

    max> Michael, some questions for you inline so I can better understand
    max> the issues you’re thinking about,

good.

    >> cable might speak USB or JTAG…)

    max> This describes a relatively high touch scenario where the device is
    max> staged and supports the so called “craft terminal” as an out-of-band
    max> management channel. This incurs additional operational (staging) and
    max> capital (extra interfaces) expenses so I tend to think in terms of
    max> non-staging and inline solutions (aka “zero touch” etc). Do you have
    max> a sense that the model you’re describing here will become more
    max> widespread?

Max, just to be clear, I'm not advocating this "high touch" scenario, I'm
just trying to understand if this is what Brian is suggesting before I make
any judgement of any kind.

    >> copy and past on the craft terminal of the certificate request.

    max> Even if we assume a “craft terminal” that is physically secured do
    max> you think it is a good idea to have the network generate the key —
    max> or do you see value in the more classic asymmetric key approach
    max> where the device generates the key itself if possible?

I think that the machine should generate it's own key, and key it secure
internally.  Many hardware modules do not support exporting their private
key...  The CSR consists of public info only (essentially a self-signed copy
of the public key, plus desired attributes).  The copy and paste of a
certificate request (CSR) is therefore of public information, but it must
handled carefully as it can be substituted along the way.

    >> needs to go. (which might be a warehouse, where it will wait as a spare part)

    max> Do you imagine that the credentials installed in 1-2 are the final
    max> credentials for the device? Or do you think it might have more
    max> generic credentials while it sits in the warehouse and be issued its
    max> final credentials after it is deployed?

When steps 1/2 are done "inhouse", then I think that both scenarios are
possible and likely.  So for instance, I would expect all military-like
organizations (probably including rescue and humanitarian entities) to have a
staging situation.  They simply can't assume there is any "online" where they
are going to do enrollment with.

    max> Do you see value in the device manufacturer providing steps 1-2
    max> during manufacturing thus saving the final customer the costs and
    max> complexities of these steps?

okay, so I'll finally bite: listed steps 1/2 are what we do now, and they
suck.  They are secure only because of the craft terminal, and devices
too small for such an interface, or operators too simple to have an RS232 on
their laptop can not play.

The "0000" and "1111" as the univeral BT headset code are shameful... [my
god, the headset could *speak* it's code to you :-)]

Yes, I want steps 1/2 done during manufacturing, but we need to bridge the
ownership gap to be bridged.

I hope Brian will answer my original email, because I'm sure that he didn't
want to re-invent the craft terminal.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Apr 2015 08:12:18 +1200

Good morning (NZ time). Some responses in line.

> any judgement of any kind.

Yes, I believe that there will be operators who want to do it this way.
I can imagine incumbent telcos doing so, just because that's the way they
work. I can certainly imagine military or other high security operators
doing so, because they are simply unwilling to trust anybody else.

I'm not advocating  this approach; I just believe that some fraction
of the market will want to keep the entire process 100% in-house,
with no MASA and no call-home.

> key...  

Oh. I'm missing something then; how does the rest of the domain learn
the public key?

> The CSR consists of public info only (essentially a self-signed copy

Exactly my point. Military installations, nuclear power stations, the
access control system for highly secure buildings,...

> want to re-invent the craft terminal.

Not specially. My whole point is that Anima infrastructure needs to be robust
against a whole variety of scenarios, regardless of what we think is the
best scenario.

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 10 Apr 2015 20:40:28 +0000

It is always morning somewhere! 

I personally disagree with the assertion that somebody with physical possession of the device in factory default state should be able to “take ownership” of the device without engaging with the vendor/cloud service. I understand that there is a long history of this model and folks are reluctant to give it up — so I expect that we’ll have to deal with it for a short while longer. I think a pragmatic position is to declare such activities as out-of-scope since they’re clearly NOT a zero touch model. This would avoid needing to weaken the zero-touch threat model to deal with an inherently problematic use case. 

Here is my justification for my position: The threat is that an attacker intercepts the device during shipping and installs malware on it. Google can help you trivially find examples of this. Mitigations of this threat include:
	a) log information on a _secure_ service (e.g. MASA approach)
	b) strong crypto authorization (e.g. netconfig owner certificates)
	c) [I’m open to other ideas?] 
Where any of these mitigations can be made to work where the target domain is offline such as an oil field or ship at sea. BUT if the mitigation can be sidestepped by physical possession checks then anybody with physical possession can inject themselves without being logged. 

The only ways I know to mitigate that threat are to use TCG style measured boot with remote attestation. This is something I agree with but since it requires hardware… I think the best approach is to layer that level of security on top of whatever inline zero-touch protocols we come up with (e.g. declare it out-of-scope here since the mitigation is also out-of-scope). 

- max

---

From: Kent Watsen <[email-masked]>
Date: Sat, 11 Apr 2015 00:04:41 +0000

>I personally disagree with the assertion that somebody with physical
>possession of the device in factory default state should be able to ³take
>ownership² of the device without engaging with the vendor/cloud service.

I agree emphatically.

>I understand that there is a long history of this model and folks are
>reluctant to give it up ‹ so I expect that we¹ll have to deal with it for
>a short while longer. I think a pragmatic position is to declare such
>activities as out-of-scope since they¹re clearly NOT a zero touch model.
>This would avoid needing to weaken the zero-touch threat model to deal
>with an inherently problematic use case.

Also agree.  A device that has been pre-staged (manually configured) is no
longer at factory default and hence no bootstrapping process will occur.

As a corollary to this, in order to thwart interdiction attacks,
installers should always factory reset equipment as the first step to the
bootstrapping process.

>The only ways I know to mitigate that threat are to use TCG style
>measured boot with remote attestation. This is something I agree with but
>since it requires hardwareŠ I think the best approach is to layer that
>level of security on top of whatever inline zero-touch protocols we come
>up with (e.g. declare it out-of-scope here since the mitigation is also
>out-of-scope).

Agreed.  The only pragmatic mitigation to interdiction is the TCG measured
boot with remote attestation, but even then it's defeatable with enough
determination and resources.  For that matter, an IDevID can only be
trusted if an HSM like a TPM is used.

IMO, equipment without said protections are laughably insecure.   If we
were to introduce levels is security, it might look like:

           Unprotected    HSM-protocted    TPM-protected
             IDevID          IDevID         secure boot
           -----------    -------------    -------------
  Gold   :                     x                 x
  Silver :                     x
  Bronze :      x

Bronze-level equipment can implement the bootstrapping protocol, but
they're not suitable for critical deployments.

Swinging the conversation around, it seems that the two proposals readout
like this (hopefully it's a fair and accurate assessment):

NETCONF Zero-touch
------------------

  What: An offline process whereby a vendor (or delegate) signs a voucher
        that allows an owner to sign the bootstrapping data.

  Pros: Addresses the problem directly (e.g., owners, vouchers, etc.)
        How bootstrapping data is accessed doesn't matter (http, usb, nfc,
etc.)
        No degradation in security when deployed on private networks.
        Results in configuration (not just keys)

  Cons: It will be difficult to track ownership through some supply chains

Bootstrapping Keyinfra
----------------------

  What: An online process whereby a vendor (or delegate) signs a voucher
        indicating that it is okay with the device joining the domain.

  Pros: Avoids supply-chain tracking issues.

  Cons: Unclear security guarantees provided by local policies.
        Security degraded on private networks.

Also, both solutions rely on the device proving itself to the network
using an IDevID.  For Zero-touch, the IDevID is only used after the device
has processed the bootstrapping data (e.g., it's configured to call home).
 For Keyinfra, the IDevID is used by the device during the enrollment
process.

Some additional thoughts:

  - The keyinfra solution could blend in the ownership voucher concept.
    That is, a MASA could dynamically sign a voucher to a registrar that
    could then sign the bootstrapping data for the device.

  - We seems that unnatural contortions are being performed to support
    consumer grade equipment (e.g., home net), where security is opt-in
    at best.

  - We should see if there are ways to mitigate the supply chain issues.
    Maybe a kiosk or a QRC printed on the receipt at Best Buys?

Thanks,
Kent

---

From: joel jaeggli <[email-masked]>
Date: Sat, 11 Apr 2015 11:03:57 -0700

On 4/10/15 1:40 PM, Max Pritikin (pritikin) wrote:
> possession of the device in factory default state should be able to
> “take ownership” of the device without engaging with the vendor/cloud
> service. I understand that there is a long history of this model and
> folks are reluctant to give it up — so I expect that we’ll have to
> deal with it for a short while longer. I think a pragmatic position
> is to declare such activities as out-of-scope since they’re clearly
> NOT a zero touch model. This would avoid needing to weaken the
> zero-touch threat model to deal with an inherently problematic use
> case.

This actually seems like a question of business model... which is not
really a problem I would expect us to  address directly.

> Here is my justification for my position: The threat is that an
> attacker intercepts the device during shipping and installs malware
> on it. Google can help you trivially find examples of this.
> Mitigations of this threat include: a) log information on a _secure_
> service (e.g. MASA approach) b) strong crypto authorization (e.g.
> netconfig owner certificates) c) [I’m open to other ideas?] Where any
> of these mitigations can be made to work where the target domain is
> offline such as an oil field or ship at sea. BUT if the mitigation
> can be sidestepped by physical possession checks then anybody with
> physical possession can inject themselves without being logged.

if customers demand it that's what you'll build, if not then whatever.

> measured boot with remote attestation. This is something I agree with
> but since it requires hardware… I think the best approach is to layer
> that level of security on top of whatever inline zero-touch protocols
> we come up with (e.g. declare it out-of-scope here since the
> mitigation is also out-of-scope).
> 
> - max
> 
>>> max> Michael, some questions for you inline so I can better
>>> understand max> the issues you’re thinking about,
>>> 
>>> good.
>>> 
>>>>>>> Just for further clarity, 1) to whom do they register the
>>>>>>> new public key?
>>>>> 
>>>>>> Their own CA, within their own network. Remember that our
>>>>>> target market for Anima includes very large networks
>>>>>> (carriers or large enterprises). But that isn't the whole
>>>>>> market, of course. Smaller enterprises may be happier to
>>>>>> farm out security functions to the cloud, although it will 
>>>>> I don't mean to be obtuse, but do I understand the process
>>>>> you are describing to be: 1) the network operator unboxes the
>>>>> system in a lab/provisioning center (It sure sounds like a
>>>>> serial console. I have learnt recently, this is called the
>>>>> "craft terminal" in telco speak.  On small devices, this 
>>> max> This describes a relatively high touch scenario where the
>>> device is max> staged and supports the so called “craft terminal”
>>> as an out-of-band max> management channel. This incurs additional
>>> operational (staging) and max> capital (extra interfaces)
>>> expenses so I tend to think in terms of max> non-staging and
>>> inline solutions (aka “zero touch” etc). Do you have max> a sense
>>> that the model you’re describing here will become more max>
>>> widespread?
>>> 
>>> Max, just to be clear, I'm not advocating this "high touch"
>>> scenario, I'm just trying to understand if this is what Brian is
>>> suggesting before I make any judgement of any kind.
>> 
>> Yes, I believe that there will be operators who want to do it this
>> way. I can imagine incumbent telcos doing so, just because that's
>> the way they work. I can certainly imagine military or other high
>> security operators doing so, because they are simply unwilling to
>> trust anybody else.
>> 
>> I'm not advocating  this approach; I just believe that some
>> fraction of the market will want to keep the entire process 100%
>> in-house, with no MASA and no call-home.
>> 
>>>>> 2) the network generates the new key, and enrolls it, I guess
>>>>> doing a copy and past on the craft terminal of the
>>>>> certificate request.
>>> 
>>> max> Even if we assume a “craft terminal” that is physically
>>> secured do max> you think it is a good idea to have the network
>>> generate the key — max> or do you see value in the more classic
>>> asymmetric key approach max> where the device generates the key
>>> itself if possible?
>>> 
>>> I think that the machine should generate it's own key, and key it
>>> secure internally.  Many hardware modules do not support
>>> exporting their private key...
>> 
>> Oh. I'm missing something then; how does the rest of the domain
>> learn the public key?
>> 
>>> The CSR consists of public info only (essentially a self-signed
>>> copy of the public key, plus desired attributes).  The copy and
>>> paste of a certificate request (CSR) is therefore of public
>>> information, but it must handled carefully as it can be
>>> substituted along the way.
>>> 
>>>>> 3) the network operator boxes the system backup and ships it
>>>>> to where it needs to go. (which might be a warehouse, where
>>>>> it will wait as a spare part)
>>> 
>>> max> Do you imagine that the credentials installed in 1-2 are the
>>> final max> credentials for the device? Or do you think it might
>>> have more max> generic credentials while it sits in the warehouse
>>> and be issued its max> final credentials after it is deployed?
>>> 
>>> When steps 1/2 are done "inhouse", then I think that both
>>> scenarios are possible and likely.  So for instance, I would
>>> expect all military-like organizations (probably including rescue
>>> and humanitarian entities) to have a staging situation.  They
>>> simply can't assume there is any "online" where they are going to
>>> do enrollment with.
>> 
>> Exactly my point. Military installations, nuclear power stations,
>> the access control system for highly secure buildings,...
>> 
>>> 
>>> max> Do you see value in the device manufacturer providing steps
>>> 1-2 max> during manufacturing thus saving the final customer the
>>> costs and max> complexities of these steps?
>>> 
>>> okay, so I'll finally bite: listed steps 1/2 are what we do now,
>>> and they suck.  They are secure only because of the craft
>>> terminal, and devices too small for such an interface, or
>>> operators too simple to have an RS232 on their laptop can not
>>> play.
>>> 
>>> The "0000" and "1111" as the univeral BT headset code are
>>> shameful... [my god, the headset could *speak* it's code to you
>>> :-)]
>>> 
>>> Yes, I want steps 1/2 done during manufacturing, but we need to
>>> bridge the ownership gap to be bridged.
>>> 
>>> I hope Brian will answer my original email, because I'm sure that
>>> he didn't want to re-invent the craft terminal.
>> 
>> Not specially. My whole point is that Anima infrastructure needs to
>> be robust against a whole variety of scenarios, regardless of what
>> we think is the best scenario.
>> 
>> Brian
>> 
>> _______________________________________________ Anima mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/anima
> 
> _______________________________________________ Anima mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Apr 2015 19:17:15 -0400

joel jaeggli <[email-masked]> and Max started a thread on the question of
whether or not some operators and some vendors will want to maintain a model
where physical possession of the device implies ownership.

I observe that for quite a number of operators the trip back to the vendor
for (initial) deployment authorization is itself a far worse attack than other
attacks.  In particular, it can change the business relationship from one of
purchaser to that of effective leasor, as it could restrict ability to
resell.

So let's not try to solve this problem, but instead consider the converse
problem.  Rather than dealing with: "there is a device in my posession that
I wish to own", to instead deal with, "There is a device not in my posession,
which I wish to claim"

    mcr> I think that the machine should generate it's own key, and key it
    mcr> secure internally.  Many hardware modules do not support
    mcr> exporting their private key...

    max> Oh. I'm missing something then; how does the rest of the domain
    max> learn the public key?

Maybe the term is CSR not clear: that's the request to get a certificate that
is sent to the CA.  It would be returned to the system to be installed as the
domain-specific certificate, and then the machine would be deployed with a
locally significant certificate.  This craft terminal mechanism is a
mitigation for the situation where we don't have a token-enabled MASA and/or
other vendor-anchored ownership certificate.

    mcr> When steps 1/2 are done "inhouse", then I think that both
    mcr> scenarios are possible and likely.  So for instance, I would
    mcr> expect all military-like organizations (probably including rescue
    mcr> and humanitarian entities) to have a staging situation.  They
    mcr> simply can't assume there is any "online" where they are going to
    mcr> do enrollment with.

    max> Exactly my point. Military installations, nuclear power stations,
    max> the access control system for highly secure buildings,...

My claim is that the equipment has already been bootstraped prior to being
placed into a warehouse.

My claim is also that we should consider the entirely online, zero-touch
situation, and consider the work-arounds for not being online as requiring a
mitigation proceedure.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Apr 2015 12:50:24 +1200

Two things...
> situation, and consider the work-arounds for not being online as requiring a

1. The comments tagged above as max> were actually brian>
(and if everybody used the de facto standard quoting convention for plain
text email, we wouldn't have that confusion).

2. I do object to your choice of words ("work-around" and "mitigation"). They
are just alternative methods, which will be used for reasons that aren't
our business. I submit that our business is to make the Anima infrastructure
work equally well (and equally securely) in each case.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Apr 2015 10:58:15 -0400

> text email, we wouldn't have that confusion).

My fault, trying to interpret a really long/deep thread with lots of stupid quoting.
And... which standard would that be? :-)

    > work equally well (and equally securely) in each case.

I think it is useful to discuss why you don't like my words, and why I don't
like the words: "alternatives methods", because I think that there could be
something deeper here.

As I see it, we are about to define a sequence of steps {A->B->C->D->E}, which
leads to creation of a secure autonomic control plane, on which intents will
be communicated, and resources distributed/allocated.

I think that all devices need to be at a well defined step in this process, and
it might be that we have to write some state machines that deal with how to
go forward, backwards, and when factory reset is the only way forward, and
when it must in fact be forbidden.

As such, if devices arrive at step C via alternative methods, having never gone
through steps A, and B, then there may be some things that we can not do in
the process.  Those alternative methods must now become documented and so
really we now have a sequence that looks like:

{(W->X->Y),(A->B)}->C->D->E.

and we can not say, if D fails, go back to B, because maybe it arrived via X
instead.  So that's why I used the terms "mitigation" --- we will instead
have a process that looks like:

  W     Q
  v     v
  A---> B ---> C

Where W and Q are distinct ways of getting to A or B from scratch.  If one
arrives via W->A, then if we say, "go back to B", then it's clear one can do
that.  If one arrives via Q->B, then when one says, "go back to B", it might
mean one has to go back to Q, and perform the step to get to B again.

There is no path W->Q here.  Q is a mitigation for the device (or morely the
device's supply chain) not having the A step available.  Maybe I'm being
pedantic, and maybe I'm violently agreeing with Brian's intention, but not
his words.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Apr 2015 08:40:58 +1200

> And... which standard would that be? :-)

I wonder about that myself, but I think that >>> came from Berkeley mail.

> pedantic, and maybe I'm violently agreeing with Brian's intention, but not

Indeed, we mainly agree. There is a point at which a device has been enrolled
with the relevant CA, and after that all devices are equally trustworthy.
There are several ways to get to that point. I think we're arguing about
whether one of those ways should be regarded as canonical.

Operationally, of course, it would be much better if there was only
one way, but in the real world that won't happen.

     Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 14 Apr 2015 18:32:07 +0000

>             IDevID          IDevID         secure boot

I was under the impression that the local policies _should_ be able to set the security guarantees — this this characteristic is a “pro”. :) 

>        Security degraded on private networks.

I’m not following this assertion. How is security degraded on a private networks? What is the threat you are thinking of and how is it mitigated by the netconf zero-touch approach? 

> has processed the bootstrapping data (e.g., it's configured to call home).

In the early version draft-kwatsen-netconf-zerotouch-01 uses the IDevID early on: 
   "When the device is accessing a Configuration Server URI that it was
   shipped with (i.e., not discovered while initializing its networking,
   it MUST do so by appending the fingerprint of its entity certificate
   to the URI's string”
But I don’t see an equivalent in draft-ietf-netconf-zerotouch-02. How does the bootstrap server know which ownership voucher to provide if it doesn’t receive the IDevID information early in the process? 

>    could then sign the bootstrapping data for the device.

I agree. I can envision a scenario where the client could accept either a MASA generated “authorization token” (which we could rename a “logged authorization” or something) -or- a ownership voucher. I’d signal what the client supports via extensions placed in the IDevID.

>    consumer grade equipment (e.g., home net), where security is opt-in

The MASA “logged authorization” approach was selected because it supports both consumer grade equipment and complex supply chains. I agree that ownership vouchers are fairly straightforward in comparison but it is too narrow to cover all the use cases. 

>    Maybe a kiosk or a QRC printed on the receipt at Best Buys?

I’d be interested in such solutions. The problem I see is that these approaches involve “public” information printed onto the receipt or onto the chassis or packaging of the device. That is a low security mechanism and could be used to, for example, minimize the risk of unrelated parties claiming a device but aren’t sufficient to provide a truly secure supply chain. 

- max

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Apr 2015 08:16:37 +1200

>>> ownership² of the device without engaging with the vendor/cloud service.

I can see how vendors might agree on that. I don't think that corporate
purchasers will agree at all, especially those with their own strong views
on security and trust. Consider the case of a military customer in country X
buying equipment from a manufacturer in country Y. I can't imagine them
accepting the need for even a momentary engagement with the manufacturer.
The risk of a backdoor is too high.

Similarly, if two companies are in competition but one of them needs to
buy equipment from the other.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Apr 2015 20:13:59 -0400

> The risk of a backdoor is too high.

I thought about this situation greatly.
If it is unacceptable for X to ever talk to Y's enrollment server, even in
some unclassified provisioning lab, then really, X would never buy Y's
equipment.  At some point, the Y equipment might need new firmware from Y's
web site... are you saying they would never download that either?
Is this realistic?

{My government has banned procurement entirely from some companies}

    > buy equipment from the other.

It seems broken from the outset...
I don't buy the argument.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Apr 2015 13:29:58 +1200

Michael,

> web site... are you saying they would never download that either?

No. Post-STUXNET and post-Snowden, I suppose that any hyper-cautious enterprise
would download the update into a clean room, scan it carefully and exercise
it in a test rig before deploying it to live devices. This is the exact opposite
of consumer behaviour, of course.

> {My government has banned procurement entirely from some companies}

Precisely for fear of backdoors (and in the case of the US, allegedly
because they *knew* that equivalent local products contained back doors).

> It seems broken from the outset...

Nevertheless, it's very common.

> I don't buy the argument.

In the end, I don't much care except that all basic Anima mechanisms, IMHO,
need to work whatever scenario applies.

    Brian

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 15 Apr 2015 01:57:27 +0000

It took me a while to read the whole thread and I would go to the basics

A data center or network operator (either service provider or enterprise) have to deploy hundreds or thousands of devices. Such orders are usually high touch and vendors know which device goes to such orders. In such scenarios, it is very expensive to do any pre provisioning or provisioning on site at installation (will avoid residential scenarios, but those are pretty similar). Having zero touch capabilities just for those use cases, where only upon FIRST delivery the zero touch is activated, would be tremendously useful.
Ownership model is simpler (as there is possibility to have only one "owner") and there are multiple ways to check if the request is coming from the "right owner". Lets try to solve the use case just for the first owner for customers that are high touch customers today.

For the residential scenarios, that would be very helpful, as residential CPEs are used until end of their lifetime and the secondary market for such devices is pretty small IMHO.

Dean

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 15 Apr 2015 15:09:47 +0000

> The risk of a backdoor is too high.

There is a pretty big “engagement” with the manufacturer when they purchase hardware and software. There is also an “engagement” when software updates, signed by the manufacturer of course, are delivered.  As secure boot, runtime integrity, threat detections etc are added these “engagements” could reasonably occur more often. What makes a zero touch authorization any different? 

I suspect your concern is that:

1) can this be used as a “backdoor” to gain management control over the device?
We’ve previously discussed that this bootstrapping only accepted when the device has been returned to factory defaults. Manufacturer authorization methods provide an additional layer of protection beyond whatever key zeroize method were used during factory reset. 

2) could inability to repeat bootstrapping result in a bricked device in the field? 
This is a serious concern. The MASA “nonceless” responses have an infinite lifetime if necessary. I presume a similar concept would apply to the netconf draft. Either of which would require that the authorization blob is available “in the field”. Storing it on the device would be problematic as it would have been erased during factory reset. It could be stored elsewhere or a solution to that could be identified. This strikes me as the most compelling reason to allow physical possession as a backdoor around zero-touch security mechanisms - although hopefully we at least provide a solution with associated “MAY” language.  

> buy equipment from the other.

Buying equipment from a suspected attacker assumes that the vendor provided secure boot integrity protections are highly trusted! I don’t see this as directly related to the problem at hand (it exists either way). 

- max

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Apr 2015 11:51:51 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> > Similarly, if two companies are in competition but one of them needs
    >> to > buy equipment from the other.
    >> 

    > In the end, I don't much care except that all basic Anima mechanisms,
    > IMHO, need to work whatever scenario applies.

Well, I think, given a craft terminal and appropriate provisioning of a
locally significant trust anchor and certificate, that we can arrange to skip
the "call home" step.
I'm just not willing to build it in as a core part of the protocol.
As I said, I'm happy if it's an alternate path.

One might ask why even do ANIMA in such a situation, but given a situation where
one builds-to-inventory, and then ships, it makes sense.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 15 Apr 2015 17:54:17 +0000

Hi Max,

>I was under the impression that the local policies _should_ be able to
>set the security guarantees ‹ this this characteristic is a ³pro². :)

True, true, but it's hand-waving language that I can't get my head around
how its realized.  This is why I wrote "unclear security".   The issue is
that bootstrapping-keyinfra provides a mechanism that can be used as part
of a bootstrapping solution, but it's not the entire solution, and not
knowing the other parts leaves the solution unclear.

>I¹m not following this assertion. How is security degraded on a private
>networks? What is the threat you are thinking of and how is it mitigated
>by the netconf zero-touch approach?

I may have misspoken, please correct me if so, but my understanding is
that the MASA doesn't run on a private network, hence it's up to the
Registrars to make a local policy decision.   Asserting that a log has
been created in an auditable location offers some protection, but without
MASA, what's the Registrar suppose to do?  There could be a simple
explanation but, again, this goes to my not understanding the complete
solution.

In the netconf zero-touch approach, the bootstrapping data is signed by
the rightful-owner's private key.  How the bootstrapping data is provided
to the device (over WAN, LAN, or off a USB flash drive) doesn't alter the
fact that the data is signed and hence equally trustworthy in all cases.

>   to the URI's string²
>But I don¹t see an equivalent in draft-ietf-netconf-zerotouch-02. How
>does the bootstrap server know which ownership voucher to provide if it
>doesn¹t receive the IDevID information early in the process?

The current version simplifies it to just the device's unique-identifier
(see examples in Section A.2).  Basically, I'm on the fence if the
unique-id (e.g., serial-number) should be used directly, or if it's too
structured and can lead to an enumeration attack and o a potential loss of
privacy.  Rest assured that the data is still safe, but others may have
gleaned it, learning details that might be used to launch a larger attack
(e.g., the tolopolgy of the network).  One remediation step is to use a
less structured ID - for instance, the md5-hash of the unique-id would
cause even statistical distribution over a 16-byte value-space.  Another
remediation could be to enable the rightful owner to both sign and
*encrypt* the bootstrap data.  Encrypted using the device's public key, as
found in its IDevID.  But this means that now the device's IDevID (not
it's unique-id), would have to be provided to the rightful owner (e.g., in
an email containing shipping information).  The question here mainly is if
this improvement in privacy (not security) is worth the additional
hassle...

>I agree. I can envision a scenario where the client could accept either a
>MASA generated ³authorization token² (which we could rename a ³logged
>authorization² or something) -or- a ownership voucher. I¹d signal what
>the client supports via extensions placed in the IDevID.

Interesting suggestion.  This is worth exploring, perhaps as an aspect of
a wholistic keyinfra solution...

>>  - It seems that unnatural contortions are being performed to support
>The MASA ³logged authorization² approach was selected because it supports
>both consumer grade equipment and complex supply chains. I agree that
>ownership vouchers are fairly straightforward in comparison but it is too
>narrow to cover all the use cases.

Exactly.  I'm beginning to think that these are fundamentally different
use-cases.   On one hand, we have an already high-touch sales process,
where the overhead of an additional vendor interaction is not a big deal,
and yet uncompromising security is needed  (this is what netconf zerotouch
is going after).  And on the other hand, we have a potentially no-touch
sales process, where the overhead of an additional vendor interaction is a
non-starter, and security is not a big deal anyway (this is homenet's
space).  Bootstrapping-keyinfra is trying to target both, which is no easy
feat..

>I¹d be interested in such solutions. The problem I see is that these
>approaches involve ³public² information printed onto the receipt or onto
>the chassis or packaging of the device. That is a low security mechanism
>and could be used to, for example, minimize the risk of unrelated parties
>claiming a device but aren¹t sufficient to provide a truly secure supply
>chain.

That is indeed the risk, and we should only view this as a strategy to try
a handle consumer-grade equipment...and not used for equipment provided by
a secure supply chain.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Apr 2015 17:03:18 -0400

comments inline.

Kent Watsen <[email-masked]> wrote:
    >> I¹m not following this assertion. How is security degraded on a
    >> private networks? What is the threat you are thinking of and how is it
    >> mitigated by the netconf zero-touch approach?

    > been created in an auditable location offers some protection, but
    > without MASA, what's the Registrar suppose to do?  There could be a
    > simple explanation but, again, this goes to my not understanding the
    > complete solution.

yes, I also don't understand the multiple-MASA, or partitioned-MASA
situation.  As far as I understood, unless there is a canonical MASA
for a given device or all the MASA flood fill data (perhaps bitcoin
block-chain like), then the increased security due to the audit process
of the MASA is reduced.

I just steal your device, put it on my private network, and it's good.

    >> In the early version draft-kwatsen-netconf-zerotouch-01 uses the
    >> IDevID early on: "When the device is accessing a Configuration Server
    >> URI that it was shipped with (i.e., not discovered while initializing
    >> its networking, it MUST do so by appending the fingerprint of its
    >> entity certificate to the URI's string² But I don¹t see an equivalent
    >> in draft-ietf-netconf-zerotouch-02. How does the bootstrap server know
    >> which ownership voucher to provide if it doesn¹t receive the IDevID
    >> information early in the process?

    > The current version simplifies it to just the device's
    > unique-identifier (see examples in Section A.2).  Basically, I'm on the
    > fence if the unique-id (e.g., serial-number) should be used directly,
    > or if it's too structured and can lead to an enumeration attack and o a
    > potential loss of privacy.  Rest assured that the data is still safe,
    > but others may have gleaned it, learning details that might be used to
    > launch a larger attack (e.g., the tolopolgy of the network).  One
    > remediation step is to use a less structured ID - for instance, the
    > md5-hash of the unique-id would cause even statistical distribution
    > over a 16-byte value-space.  Another remediation could be to enable the
    > rightful owner to both sign and *encrypt* the bootstrap data.
    > Encrypted using the device's public key, as found in its IDevID.  But
    > this means that now the device's IDevID (not it's unique-id), would
    > have to be provided to the rightful owner (e.g., in an email containing
    > shipping information).  The question here mainly is if this improvement
    > in privacy (not security) is worth the additional hassle...

I'm generally skeptical about privacy improvements by having non-enumerable
IDs.  I don't think that there is any privacy improvement from changing the
observation from unique-ID=00001 to unique-ID=MDAwMDEK, if it's always
the same.

Now, the question is, what is the enumeration attack you are worried about?
I agree that it might be beneficial to eliminate that, but maybe it doesn't
matter.  

    >> I agree. I can envision a scenario where the client could accept
    >> either a MASA generated ³authorization token² (which we could rename a
    >> ³logged authorization² or something) -or- a ownership voucher. I¹d
    >> signal what the client supports via extensions placed in the IDevID.

    > Interesting suggestion.  This is worth exploring, perhaps as an aspect
    > of a wholistic keyinfra solution...

Yes, I agree.
I prefer "logged authentication token", btw.

    >> The MASA ³logged authorization² approach was selected because it
    >> supports both consumer grade equipment and complex supply chains. I
    >> agree that ownership vouchers are fairly straightforward in comparison
    >> but it is too narrow to cover all the use cases.

    > where the overhead of an additional vendor interaction is not a big
    > deal, and yet uncompromising security is needed (this is what netconf
    > zerotouch is going after).  And on the other hand, we have a
    > potentially no-touch sales process, where the overhead of an additional
    > vendor interaction is a non-starter, and security is not a big deal
    > anyway (this is homenet's space).  Bootstrapping-keyinfra is trying to
    > target both, which is no easy feat..

I actually disagree that the security of the homenet space is "not a big deal".
This is what got us bot-nets.  If someone can gain control over millions of
light bulbs, and can turn them on/off at the same time, it's a really really
really big deal.

Having said that, I believe that a supply-chain interaction (which might not
go all the way back to the vendor) is potentially acceptable in the long run.
We just have to have a way to get product deployed without a chicken/egg
situation.

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Thu, 16 Apr 2015 03:28:17 +0000

Hi,
Please see my reply inline.

  >From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
  >Sent: Wednesday, April 15, 2015 9:30 AM
  >To: Michael Richardson; [email-masked]
  >³take
  >> If it is unacceptable for X to ever talk to Y's enrollment server,
  >> even in some unclassified provisioning lab, then really, X would never
  >> buy Y's equipment.  At some point, the Y equipment might need new
  >> firmware from Y's web site... are you saying they would never download that
  >either?
  >> Is this realistic?
  >
  >No. Post-STUXNET and post-Snowden, I suppose that any hyper-cautious
  >enterprise would download the update into a clean room, scan it carefully and
  >exercise it in a test rig before deploying it to live devices. This is the exact
  >opposite of consumer behaviour, of course.
  >

Whether to update software is usually determined by the owner of the device. Besides, the device and the network basically shouldn't stop working no matter the software is updated or not.
A main difference between software update server and MASA is that MASA'S authorization token determines networking. 

I summarize MASA's work in the draft, correct me if I am wrong:
1. check domain confliction of a joining device.->This could forbid the stolen device being used by others(similar as Apple products), however a device can belong to one owner at a time but might belong to different domains/sub-domains, again we fall into the discussion of whether 'domain id== owner id', and IMO, the answer is No. 
2. remotely audit event.->whether the information is remotely audited should not impact device joining.
3. validate the registrar for the joining device.->the validation could be done locally as well.

I don't have any clue why MASA should participate in bootstrapping(even as an option) by considering the above three items.
However, IMO, as MASA is already optional in the current version, it could be used to realize a more valuable task(if required) and not only at the bootstrapping phase to validate the integrity of the joining device/all the existing devices in the domain and alert domain if any abnormality happen. 

Ana