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:[email protected]] 代表 Michael Richardson 发送时间: 2019年6月19日 8:47 收件人: Warren Kumari <[email protected]> 抄送: [email protected]; OpsAWG Chairs <[email protected]> 主题: Re: [OPSAWG] WG adoption poll for draft-wkumari-opsawg-sdi-04 Warren Kumari <[email protected]> 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 <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
