On Jul 9, 2018, at 4:54 PM, Joe Clarke <[email protected]> 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. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
