Hi Mike,
I wholeheartedly agree with your thoughts.
How about saying "if you need to support a remote shell for HCD
configuration updates, then you SHOULD use SSH and SHOULD
NOT use non-standard or proprietary shell protocols". (I know we
should separate each of those imperatives into separate numbered
recommendations).
Among the Trusted Computing Group participants in the Network
Equipment WG, some still use SSH (all of them hate Telnet), some
use SNMPv3 over TLS, some are shifting to NETCONF (which is a
pain due to proprietary YANG modules, IMHO), and some still use
proprietary shell interfaces. And quite a few don't have a single
solution across their product lines, unfortunately.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
(to 30 April 2020) 203 W Oak St Ellettsville, IN 47429 812-876-9970
On Tue, Feb 4, 2020 at 10:31 AM Michael Sweet <msweet at msweet.org> wrote:
> Ira,
>> > On Feb 4, 2020, at 9:52 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
> >
> > Hi Mike,
> > ...
> > My own intuition is that remote shells should not be used in HCDs
> > because, if there is any implementation bug in the shell (e.g., SSH),
> > then a privilege execution attack becomes easy to implement. Do
> > you disagree with that recommendation?
>> 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.
>> 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.
>> 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.
>> ________________________
> Michael Sweet
>>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ids/attachments/20200204/ff0c96a0/attachment-0001.html>