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

[Qin Wu <[e-mail]>]

Interesting, try to understand the key difference between device enroll in secure environment and device enroll in in secure environment?
Does the mechanism proposed in this draft work for the device behind the firewall or NAT?

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