Hi,
I believe the MUST/SHOULD debate pertains only to the recommendations section,
the rest of the documents sticks to description of current status apart from
the documented deprecations that no sensible implementation would do today,
i.e. a few deletions but no updates.
The discussion focusses specifically the MUSTs for implementations. Now there
is not much point in making recommendations for the past (i.e. implementations
that are actually already in the field), so I think that it is implicit that
the recommendations are for new implementations and upgrades. I believe the
discussion sums to: if we add a note to make this explicit, then it should be
clear for all. What is more, if we mark the deltas then we may actually be
providing a useful service for implementers of current products: we can
explicitly point out where we believe the implementations which strictly follow
previous draft should be enhanced.
For example:
Deployment Best Practices
In view of the observations about the security issues described above, a
network administrator MUST NOT rely on the obfuscation of the TACACS+ protocol
and TACACS+ MUST be deployed over networks which ensure privacy and integrity
of the communication. TACACS+ MUST be used within a secure deployment. Failure
to do so may impact overall network security.
The recommendations for TACACS+ Server and client implementations below are
intended to guide new implementations and upgrades to current implementations.
Some of these recommendations are stricter than previous guidance, these will
be marked [*] so that implementers of current can see where this WG recommends
that improvements should be made to enhance security.
…
On 10/07/2018, 4:56, "Alan DeKok" <al...@deployingradius.com> wrote:
On Jul 9, 2018, at 9:17 PM, Scott O. Bradner <s...@sobco.com> wrote:
> imo - documenting existing practice is not the same thing as “rubber
stamping”
Perhaps my messages were unclear.
I'm not opposed to *documenting* existing practices. I'm opposed to
*endorsing* existing practices. Especially where those practices are insecure.
There is every reason for the spec to say "A, B, and C are OK if you hold
your nose. D, E, and F are right out."
But that suggestion is apparently controversial. The reasons given are
"existing practices".
Which sounds to me like there's a requirement for a "rubber stamp"
approval of existing implementations.
Let me be clear: if the protocol and existing implementations allow for
unauthenticated, insecure, remote access to a root shell... then the spec
SHOULD say "OMG that's a terrible idea, don't do that. Yes, I know everyone's
done that for 20 years. It's bad. Really, really, bad. Don't do it.
Honestly, bad things will happen."
That's largely where we are today with TACACS+:
a) we document existing practices and implementations, no matter how
insecure [1]
or
b) we describe the protocol, along with recommendations for how best to
secure it
I choose (b). There is non-trivial support for (a).
It's not clear to me why this position is in any way controversial, or
misunderstood.
Alan DeKok.
[1] Without mentioning pesky issues like "security". I mean, why warn
people that bad things can happen?
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
