On Jul 9, 2018, at 5:36 PM, Joe Clarke <jcla...@cisco.com> wrote: > I hear and understand what you're saying. And if this were a net new > protocol, I'd agree with you 100%. But the mandate for this document is > to describe how T+ is implemented today[1].
So... a) we rubber-stamp existing practices and implementations, no matter how insecure or b) we describe the protocol, along with recommendations for how best to secure it. I think that (b) is the best approach. I don't understand why we would ever choose (a). > Today, people are deploying > it with all sorts of security issues because that's how the protocol works. Perhaps the IETF could give guidance on best practices? Along with what parts of the protocol are insecure, and should be avoided? > On top of that, new implementations that change behavior could be > incompatible with existing clients. If those existing clients are insecure and allow people to pwn your network, then I don't really have any sympathy. And as always, vendors are free to ignore the recommendations of the specification. But at least after the admin gets pwned, he can point to the spec and say "YOU KNEW. IT'S YOUR FAULT." The alternative is to tell the admins "We knew, but we didn't care." That's not acceptable. > As a new _implementor_ of a server, I'd rather not repeat the protocol > flaws of the past if a new security model is coming (i.e., within a new > draft). So my thinking is that we recommend what we can for deployment. > Will Sec AD accept this? I don't know. I don't know that they've been > asked. I've been on secdir for a long time now, and have seen hundreds of reviews. If the WG punts on security, secdir will punt the draft back to the WG with a comment of "you can do better." I'm here *as* the early secdir review. Look, I can go away and stop fighting this issue. You'll spend 2 years updating the draft. Which will then get punted by secdir. And you'll be back in the same place you are today. Again, it looks VERY much to me like the goal is to publish an "IETF stamped" version of TACACS+. And that the content of the document is almost irrelevant. That's just not how this works. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
