Re: draft-jones-opsec-01.txt comments: in-band management

["Joel N. Weber II" <ietf-opsec@joelweber.com>]

> So, the approach I've been taking is to make the requirement
> generic "secure in band management" with the example citing
> one or more current technologies/praticies as as SUGGESTIONS
> of ways to meet the requirement.   The idea is that SSH
> or IPsec or RADIUS/DIAMETER/KERBEROS may not be best
> way to implement FOO 5 years from now and we want the
> requirement (but probably not the implementation) to
> age as gracefully as possible.
>
> If people have suggestions for ways to tie the current
> implementations more strongly to the requirements
> without precuding better implemetaionts later, I'm all for
> it.
>
> I'd love to say "SSH, no telnet", "SNMPv3, no SNMPv1",
> "SCP/SFTP, no TTP".

We can always update the document in five years.  The C in BCP does
stand for something...

RADIUS/DIAMETER/KERBEROS may be something where we don't want to
mandate any one protocol, and be very deliberately vague.

I suspect we can easily get rough consensus that SSH is the only
widely deployed secure remote terminal protocol, and therefore it is a
reasonable lowest common denominator that everyone should support.  If
something better comes along three years from now, vendors can
implement that in addition to the required SSH.  (And we should
probably explicitly say SSHv2.  What I've seen of the SSH working
group leaves me with the impression that the SSHv2 protocol is
generally quite adaquate, and it seems to generally have extensibility
in the right places, more or less, and I'm kind of skeptical that we
will ever see an SSHv3 protocol.)

Has anyone got experience with the syslog-sign protocol, and the
reliable delivery protocol for syslog?

Is there anyone who's actually going to object if we mandate that STFP
and SNMPv3 be available?

(I'm assuming that the old insecure protocols can be left available at
the vendor's discretion, as long as they aren't enabled by default.)