On 10/07/2018 02:56, Alan DeKok wrote:
On Jul 9, 2018, at 9:17 PM, Scott O. Bradner <[email protected]> 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.
Could it be that we misunderstood each other as to what b) pertains to?
a) is obviously wrong as we certainly don't have to stop at documenting
current practices or even care about current practices if they result in
an insecure deployment.
For b) I don't find it controversial as long as we can agree that
"implementation" means "how clients and servers implement documented
protocol" and not "how do operators deploy clients and servers". I.e.
"implementation" and "practice" refer to two different things.
Then we can comb for ambiguous statements like "server MUST implement
CHAP in exclusion to PAP" and reword them to say "operators MUST use
servers and clients configured to disallow authentication methods other
that CHAP".
Andrej.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
