Re: [OPSAWG] WG adoption poll for draft-wkumari-opsawg-sdi-04

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: Warren Kumari [mailto:[e-mail]] 
发送时间: 2019年6月24日 16:37
收件人: Qin Wu <[e-mail]>
抄送: Michael Richardson <[e-mail]>; [e-mail]; OpsAWG Chairs <[e-mail]>
主题: Re: [OPSAWG] WG adoption poll for draft-wkumari-opsawg-sdi-04

On Mon, Jun 24, 2019 at 2:51 AM Qin Wu <[e-mail]> wrote:
>
> Interesting, try to understand the key difference between device enroll in secure environment and device enroll in in secure environment?

I'm unsure what you are asking; I'm guessing perhaps you meant "in an insecure environment"?
This completely depends on what you mean by "insecure", but "probably". As always, once the device has been configured, if an attacker has physical access to the device, they can probably do things like unsolder the flash / nvram and read the config off that -- but that has nothing to do with this technology, it is an existing issue.

If you use this mechanism to initially configure the device, and the network is compromised, and the attacker knows the serial number / UUID of the device, and the attacker can provide DHCP, the attacker
*could* make the device download and install a config file --- this largely means that the attacker could (temporarily) steal the device - but threat seems a: unrealistic and b: the threat is minor / you have much larger issues :-)

[Qin]: Thanks Warren for clarification , would you mind clarifying further a little bit difference between SZTP and SDI? E.g., control of initial configuration on owner of
the device vs control of initial configuration on the manufacturer? Security level, complexity, weakness, strength etc.

> Does the mechanism proposed in this draft work for the device behind the firewall or NAT?

Yes -- the device *only* needs to be able to download the (encrypted) config file, it doesn't need to contact anything else, nor does anything need reach the device.
This means that it can be run behind a NAT, firewall, or a even a network which is completely disconnected from the Internet.

>
> -Qin Wu
> -----邮件原件-----
> 发件人: OPSAWG [mailto:[e-mail]] 代表 Michael Richardson
> 发送时间: 2019年6月19日 8:47
> 收件人: Warren Kumari <[e-mail]>
> 抄送: [e-mail]; OpsAWG Chairs <[e-mail]>
> 主题: Re: [OPSAWG] WG adoption poll for draft-wkumari-opsawg-sdi-04
>
>
> Warren Kumari <[e-mail]> wrote:
>     > Here is a link to the slidedeck from IETF104 to refresh your memory -
>     > https://datatracker.ietf.org/meeting/104/materials/slides-104-opsawg-draft-wkumari-opsawg-sdi-01.pdf
>     > -- basically the entire document is summarized in 2 slides (slide 9,
>     > 10).  If you'd prefer video -- 
> https://youtu.be/a479Zohc5yg?t=1266
>
>     > The main design criteria for this was to be as simple as possible, to
>     > make it trivial to implement and use. This is specifically designed to
>     > just augment existing auto-install functionality; there are much more
>     > ambitious and fully featured solutions (such as ANIMA and RFC 8572)
>     > available for those who can / want to use them.
>
> Your claim that BRSKI is too complex is interesting, and I'd like to discuss this with you over beer.  But, I appreciate you trying to do this.
> Saving CO2 expended by silly airplane flights is appreciated.
>
> We did consider a protocol such as you describe.
> The limitation is that it does not necessarily enroll the new device into the ISP's security domain, and we really wanted that.
>
> The Config file provided could do that, and as you say, some staging mechanism could also use ssh to do that as well.  But, that wouldn't really be a standard, and we needed something more specific.
>
> I think you need a bit more text to explain why the device should trust the DHCP server; and also how the owner convinces the manufacturer to turn over this key.  As written, it looks like if I get a good look at the label of a BFR I have a good chance of getting the key, and I'm sure you intend something more involved.
>
> It's unclear to me if this key should be retained in the factory reset situation or not; I think you offer both possibilities, but each version has some security gotchas, and I think it needs to be explained.
>
> I would like you to consider specifying a standard format for the encrypted
> configuration.   CMS, PGP, JOSE, COSE... pick one or more.  That way, we can
> have tools that can support a multiple of vendors equipment.
>
> Failing such a choice, I don't see anything in this description which a manufacturer can't unilaterally do today.  So maybe it's a BCP, and and it can go into an RFP. I don't think it's Informational: BCP or STD.
>
>     > I'd really appreciate your review and comment; it's short (if you
>     > ignore the ASCII art diagrams and example appendix and similar it is 7
>     > or 8 pages, and much of that is background).  W
>
> Adopt it.
>
> ps: it would be nice if the initial DHCP request included a MUD URL, so that
>     the infrastructure can know what the device is expected to do,
>     particularly if that might involve calling home to get the latest
>     firmware before operating.
>     Should the device get any kind of Internet access from the DHCP server?
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works  
> -= IPv6 IoT consulting =-
>
>
>


--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf