On Jul 9, 2018, at 5:17 PM, Andrej Ota <and...@ota.si> wrote: > I think that forbidding some parts with MUST would go against the original > mandate for this draft which I understood to be documenting what's used and > specifically not working to do a revision of protocol (which I would love to > hide behind TLS).
The IETF is not about rubber-stamping existing implementations or practices. As a case in point, in 1993, the original RADIUS implementations had provisions for "change user password". That was remove (in *1993*), because it was insecure. I doubt very much that the security requirements have been *relaxed* in the subsequent 25 years. > The problem with the protocol as it's implemented today is that it's "unsafe > at any speed". There is nothing that either servers or clients can do to > change that on a protocol level. The only sensible normative text would be > MUST NOT implement. This in my mind shifts the focus from implementation > constraints to operational requirements. I disagree. There are portions of the protocol which are vaguely "OK", such as insecured names/passwords being sent in the clear over a management network. Ugly, but somewhat acceptable. There are portions of the protocol which *no one* would agree is a good idea today. e.g. sending secrets to a client. That's just... bad. > If we there isn't even one sensible implementation band aid (and I certainly > don't see one), we can only apply deployment band aids. There are many sensible implementation suggestions. > Net sum of both is that the document veered away from normative and into > realm of "here are the facts about insecurity of the protocol, use your best > judgement when deploying". > > We can certainly turn the draft back into more normative but I don't think > that we can do anything to the protocol itself that would salvage it in any > useful form whatsoever. The point (again) is that we should document the protocol, *and* recommended best practices. If you don't think that the protocol is salvageable at all, then please withdraw the draft. If you think we *can* document best practices, then we should do so. If you think documenting best practices isn't productive, then you will get roundly trounced when all of the non-TACACS+ people read it, and go "OMFG you can't *do* this in 2018." Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
