On 07/10/2018 12:34 PM, Alan DeKok wrote:
On Jul 10, 2018, at 3:52 AM, Andrej Ota <[email protected]> wrote:
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.
The draft should document how to implement *and* deploy TACACS+ as securely as we know
how. If that "invalidates" current implementations and practices, too bad.
Again, vendors and administrators are free to ignore the recommendations of
the draft. But they need to *know*.
If the draft permits deployments we know to be insecure, then that's wrong. And yes,
such practice *would be* "rubber stamping" existing practices.
While the requirement is to document the historical protocol, that does
*not* mean endorsing 20 year-old insecure practices. The IETF has a
responsibility to secure the Internet, among other things. Where that
responsibility conflicts with vendor / operator desire to do insecure things,
then the larger Internet security will prevail.
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".
PAP is fine so long as (a) it's in a management network, or (b) it's
"protected" by the obfuscation mechanism.
The spec should just describe the requirements. How the implementors and
administrators deploy it is up to them.
e.g. "PAP MUST NOT be used outside of management networks, unless the packets are
protected by the obfuscation mechanism."
Actually, both PAP and CHAP are irrelevant in this case. If Eve is in a
position to intercept TACACS+ traffic, she can flip a single bit in the
authentication response and that will ensure that the device (client)
will consider authentication to have succeeded. Obfuscation doesn't
help, only secured transport does.
Thus it's irrelevant to specifically mention any particular currently
used authentication method as all of them fail in exactly the same way
*and* it's irrelevant to distinguish between obfuscated and
non-obfuscated variety as MitM will succeed regardless.
Since this makes secured transport a minimal necessary requirement for
any secure deployment, what benefit is there to try and find further
examples of what can be mandated if none of the mandates would
meaningfully change the end result?
Andrej.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
