Thanks for the reply, Andrej. Additional comments below. On 5/10/18 10:45, Andrej Ota wrote: >>>> 9.1. General Security of The Protocol >>>> >>>> TACACS+ protocol does not include a security mechanism that would >>>> meet modern-day requirements. Support for MD5-based crypto pad >>>> encryption fails to provide any kind of transport integrity, which >>>> presents at least the following risks: >>>> >>>> Accounting information may be modified by the man-in-the-middle >>>> attacker, making such logs unsuitable and untrustable for auditing >>>> purposes. >>>> >>>> Only the body of the request is encrypted which leaves all header >>>> fields open to trivial modification by the man-in-the-middle >>>> attacker. For this reason, connections with >>>> TAC_PLUS_UNENCRYPTED_FLAG are disallowed, as mentioned in the >>>> recommendations section. >>> >>> JC: Disallowed for discouraged? This is a doc defining a >>> currently-deployed protocol. Implementations MAY allow for this to >>> work. However, from a best current practice standpoint, this should be >>> strongly discouraged. > > So strongly to put it as SHOULD NOT or just "strongly"?
I think SHOULD NOT is fine. > > > > I think this paragraph is a bit wonky as well as it sounds to me like header > is vulnerable, but the "encrypted" body isn't, which is very far from the > truth. > > One thing is s/encrypted/obfuscated/. Good catch. > > The other thing is lack of integrity checking and known or chosen plaintext > combo leading to MitM, where I can claim I'm Ann or Bob, even though my > authorization attempt was using username Eve in most trivial of ways. I > wouldn't want to even remotely imply that the obfuscation is somewhat saver > that plain-text header, when I can do trivial MitM things like this. I think additional clarification as to why this should not be used is good. I just want the document to maintain its connection to the fact that T+ is deployed today. While we can influence new implementations, this is an informational doc on how this protocol is currently designed while documenting known pitfalls to hopefully avoid. >>> >>> >>>> 9.3. Security of Authorization Sessions >>>> >>>> Authorization sessions MUST be used via secure transport only as it's >>>> trivial to execute a successful man-in-the-middle attacks that >>>> changes well-known plaintext in either requests or responses. >>> >>> JC: Your statement makes a lot of sense, but I struggle with how this >>> can be achieved in the current implementation of T+. To use normative >>> language here, you are saying that all T+ servers and all NASes must >>> implement something like an IPSec tunnel to exchange authz details? >>> Again, I get the recommendation, but in light of existing, interoperable >>> implementations, I don't see this being a reality. >>> > > Maybe we could reword this that it would be clear to the audience that one > could also declare a transport path where it's very unlikely to perform a > MitM, to be secure enough for the purpose of this RFC. > > Ideally the RFC should make it clear that it is up to the operator to > determine what technology to deploy (IPSec or steel pipes without dynamic > routing protocols both work for me), but they should be acutely aware that no > matter what they do, T+ is inherently MitM prone and they really, really > should act accordingly. Agreed. I think some rewording is good. In that context, I think strong normative text is fine as there are options to a NAS-to-server IPSec tunnel. > >>> >>>> 9.6. TACACS+ Server Implementation Recommendations >>>> >>>> The following recommendations are made when implementing a TACACS+ >>>> server: >>>> >>>> The Server SHOULD NOT accept any connections which have the >>>> TAC_PLUS_UNENCRYPTED_FLAG set and SHOULD reject those packets with >>>> applicable ERROR response for type of packet. >>>> >>>> The configuration of dedicated secret keys per individual client MUST >>>> be supported by the Server implementation. It is also recommended >>>> that Servers SHOULD warn administrators if secret keys are not unique >>>> per client. >>>> >>>> If an invalid shared secret is detected, Servers MUST NOT accept any >>>> new sessions on a connection, and terminate the connection on >>>> completion of any sessions previously established with a valid shared >>>> secret. >>>> >>>> The Server implementation must allow the administrator to mandate: >>> >>> JC: Should this be MUST? I ask while still grappling with the use of >>> such strong language for an informational doc citing recommendations >>> when so many existing implementations exist in the wild. > > This one is a mixed bag and maybe we should throw this one out and simply > state that plain login has one set of problems (e.g. clear-text passwords on > the wire), but CHAP has the other set of problems (e.g. central repository of > clear-text passwords). > > Maybe we should clarify that and leave it to operators to decide which risk > is more acceptable in their environment. That works for me. > >>> >>>> >>>> TAC_PLUS_AUTHEN_TYPE_CHAP for authen_type >>>> >>>> TAC_PLUS_AUTHEN_METH_TACACSPLUS for authen_method in authorization >>>> >>>> Minimum length for shared secrets. >>>> >>>> 9.7. TACACS+ Deployment Best Practices >>>> >>>> Due to above observations about the TACACS+ protocol, it is critical >>>> to only deploy it using secure transport. A secure transport for >>>> TACACS+ is defined as any means that ensure privacy and integrity of >>>> all data passed between clients and servers. There are multiple >>>> means of achieving this, all of them beyond the scope of this >>>> document. >>>> >>>> Symmetric encryption key represents a possible attack vector at the >>>> protocol itself. For this reason, servers SHOULD accept only those >>>> network connection attempts that arrive from known clients. This >>>> limits the exposure and prevents remote brute force attacks from >>>> unknown clients. >>>> >>>> Due to the security deficiencies of the protocol, it is critical that >>>> it be deployed in a secure manner. The following recommendations are >>>> made for those deploying and configuring TACACS+ as a solution for >>>> device administration: >>>> >>>> Secure the Deployment: TACACS+ MUST BE deployed over networks >>>> which ensure an appropriate privacy and integrity of the >>>> communication. The way this is ensured will depend upon the >>>> organizational means: a dedicated and secure management network >>>> where available in enterprise deployments, or IPsec where >>>> dedicated networks are not available. >>> >>> JC: This dedicated and restricted network, I agree with. This is >>> realistic in the vast majority (if not all) of T+ implementations. But >>> this dedicated network is not necessarily secure in the IPSec sense. I >>> can run a physical wire from all NASes back to my T+ server, but that >>> doesn't mean that the transport ensures integrity or confidentiality. > > Hmm ... maybe we should not use the word "transport" above as this primes the > reader to start thinking about "OSI transport layer" or "Transport Layer > Security" > > How can we better describe that private (and presumably physically reasonably > secure) network infrastructure suffices, even though there's no integrity or > privacy guarantees in the crypto sense? You could say like you stated above that ideally T+ is deployed over a transport that is cryptographically secure (i.e., one that does ensure integrity and confidentiality), or it is deployed onto a network that is dedicated to T+ and thus physically isolated from other user traffic. > > >>> >>> JC: My (contributor) recommendation is to say MUST to this and SHOULD to >>> the encrypted transport given that the latter is likely not done in the >>> majority of deployments today (though I'm willing to hear the argument >>> here). > > So, if I understand correctly: MUST have network which is MitM-resistant and > sniffing-resistant (terms subject to further refinement) and SHOULD use some > kind of crypto to be on the safe side. Yes, that's my recommendation. Joe _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
