On 7/9/18 17:11, Alan DeKok wrote: > On Jul 9, 2018, at 4:54 PM, Joe Clarke <jcla...@cisco.com> wrote: >> Below are some of my comments. They mainly revolve around the strength >> of the normative language with respect to the fact that this draft is >> supported to document the protocol as it is today. To me, the security >> considerations should reflect best common practices without >> over-enforcing things that would invalidate current implementations. > > I think that the security considerations section *should* invalidate > insecure implementations. > >> But I want the WG's thoughts on this. How do we handle the case where >> we have existing deployments that we want to document while at the same >> time recommending new _implementations_ do better things? > > We recommend that *all* implementations do the Right Thing. > > If an admin installs a product released before the recommendations, then it > clearly won't comply. That's life, and there isn't much we can do about it. > > But there's just no reason to allow new releases to ignore modern security > practices. > >> And if new >> implementations should be using a new security paradigm to be described >> in a new document, do we need strong normative language in this draft? > > Yes. > >>> TACACS+ servers MUST NOT accept any new sessions on any connection where an >>> invalid shared secret is detected. TACACS+ servers MUST terminate the >>> connection on completion of any sessions that were previously established >>> with a valid shared secret on that connection. >> >> The MUST here seems too strong given that some implementations that are >> working today may not/may do these things. These don't seem to be >> things completely within the operator's control as they deploy T+. > > These implementations are written before modern security practices. We > can't invalidate software that's already written and running in the wild. > > We *can* recommend that vendors && admins have the best possible security > in the products they ship and use. > >>> TACACS+ server and client implementations MUST treat shared secrets as >>> sensitive data to be managed securely. >> >> How is this done? > > "implementation specific". :( > >> This seems like it could be handled in different >> ways, and making this a mandatory requirement could invalidate current >> implementations. > > One word: upgrade. > >>> TACACS+ client implementations SHOULD deprecate this feature by treating >>> TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. >> >> So, again, strong normative language makes sense if I'm building a new >> implementation, but this is a doc to define the protocol as-is. > > And, to describe how to *use* the protocol as securely as possible, given > it's limitations. > >> In >> light of that, I am asking the WG if we need to go down this path or >> should we try and focus on recommendations, especially for operators, >> that can better secure the T+ they have today. > > I think that if the WG punts on security, the security area directorate > will punt the document back to the WG. And say "fix it". > > This isn't about invalidating current implementations. It's about telling > people that *new* implementations, or new *releases*, have to be as secure as > possible. > > If the WG punts on security then we might as well add a note to the > document saying "using this protocol will ensure that hackers will pwn your > equipment". Because it will be absolutely true. > > And then *no one* will want to implement it.
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]. Today, people are deploying it with all sorts of security issues because that's how the protocol works. Maybe they are trying to do it as securely as they think is possible, and that's good. But there's only so much they can do within the scope of the protocol as it exists today. To _that_ end, I strongly feel we _must_ provide clear guidelines to help implement T+ as securely as is possible. But people need to be aware that until a better security model is created, those steps are limited. On top of that, new implementations that change behavior could be incompatible with existing clients. [1] As I recall, the ultimate goal of the work was to be able to add modern security to T+. Before that could happen, the WG agreed that T+ should be documented -- in an informational document -- to set context. Simply documenting that this protocol is insecure, good luck and goodnight was not desirable, so a more robust security considerations was crafted mainly driven by your work, Alan. And to the extent that operators can help themselves with securing what they have, I'm all for it. 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. What I can do is request an early review from SEC-DIR to specifically get their expert review on the security section. Joe _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
