attachment-0001

<div dir="ltr"><div>Hi Mike,</div><div><br></div><div>I wholeheartedly agree with your thoughts.</div><div><br></div><div>How about saying "if you need to support a remote shell for HCD</div><div>configuration updates, then you SHOULD use SSH and SHOULD <br></div><div>NOT use non-standard or proprietary shell protocols".  (I know we <br></div><div>should separate each of those imperatives into separate numbered <br></div><div>recommendations).</div><div><br></div><div>Among the Trusted Computing Group participants in the Network</div><div>Equipment WG, some still use SSH (all of them hate Telnet), some</div><div>use SNMPv3 over TLS, some are shifting to NETCONF (which is a <br></div><div>pain due to proprietary YANG modules, IMHO), and some still use<br></div><div> proprietary shell interfaces.  And quite a few don't have a single</div><div>solution across their product lines, unfortunately.<br></div><div><br></div><div>Cheers,</div><div>- Ira</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG</div><div>Co-Chair - TCG Metadata Access Protocol SG<br></div><div dir="ltr">Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>(permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434</div><div>(to 30 April 2020) 203 W Oak St  Ellettsville, IN 47429  812-876-9970<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 4, 2020 at 10:31 AM Michael Sweet <<a href="mailto:msweet@msweet.org">msweet@msweet.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ira,<br>
<br>
> On Feb 4, 2020, at 9:52 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> wrote:<br>
> <br>
> Hi Mike,<br>
> ...<br>
> My own intuition is that remote shells should not be used in HCDs<br>
> because, if there is any implementation bug in the shell (e.g., SSH),<br>
> then a privilege execution attack becomes easy to implement.  Do<br>
> you disagree with that recommendation?<br>
<br>
SSH is used in a lot of network equipment (routers, in particular) where it is a means of doing configuration.  You aren't dropped into a bash shell, it is a restricted environment specifically for the purpose of configuration and maintenance, and there are no standards for a lot of that configuration and maintenance.<br>
<br>
My pragmatic recommendation is that if (and only if) a HCD needs a secure mechanism for remote configuration or maintenance that is not handled by an existing standard protocol, and the vendor uses a command-oriented interface for doing so, the vendor should use SSH to wrap their interface.  Historically such interfaces have used TELNET (!) or other clear-text "protocols" which are obviously insecure.<br>
<br>
Thankfully the list of potential things you'd need such an interface for continues to grow shorter over time, and many of these interfaces have been replaced with web-based alternatives (with their own set of security issues, not the least of which is web browsers not liking self-signed IoT certs...), but as a security guideline we should (IMHO) be pragmatic and provide guidance that is most likely to be followed.<br>
<br>
________________________<br>
Michael Sweet<br>
<br>
<br>
<br>
</blockquote></div>