Hi Joe,
We did, but also all three of us got a bit bogged down by other work. I have to wrap up section 9 "digest" while Douglas and Thorsten are doing similar for other sections where they got through the mail history and they're wrapping that up to send out an e-mail as well. Considering the amount of work that we have to do all at once, we definitely don't want more digests to happen. The rest of the answer is interleaved below. > On 10 May 2018, at 15:15, Joe Clarke <jcla...@cisco.com> wrote: > > Hello, T+ authors. Did you have a chance to read over my comments > below? What thoughts do you have? Some of these points admittedly need > some discussion. > > Thanks. > > Joe > > On 4/30/18 10:30, Joe Clarke wrote: >> On 4/15/18 02:27, Douglas Gash (dcmgash) wrote: >>> Hello Opsawg, >>> >>> We have uploaded a new version of the TACACS+ informational draft which >>> includes corrections for typos over the document as a whole, but also >>> revised the security section. We anticipate this security section will get >>> most comments, so it is reproduced below. >>> >>> We will endeavor to be much more reactive to comments, whether on section >>> below, or any other in rest of uploaded document. >> >> Thank you, Douglas. My individual comments on this new security >> requirements section in line below (since you copied it to email). >> >>> 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 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/. 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. >> >>> For these reasons, users deploying TACACS+ protocol in their >>> environments MUST limit access to known clients and MUST control the >>> security of the entire transmission path. Attacks who can guess the >>> key or otherwise break the obfuscation will gain unrestricted and >>> undetected access to all TACACS+ traffic. Ensuring that a >>> centralized AAA system like TACACS+ is deployed on a secured >>> transport is essential to managing security risk of such an attack. >> >> JC: s/Attacks who/Attackers who/ Agreed. >> >> >>> 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. >> >>> 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. >> >>> >>> 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? >> >> 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. >> >> >>> >>> Do not use the TAC_PLUS_UNENCRYPTED_FLAG option. >>> >>> Always configure a secret key (recommended minimum 16 characters) >>> on the server for each client. >>> >>> Consider shared secrets to be sensitive data, and manage securely >>> on server and client. >>> >>> Change secret keys at regular intervals. >>> >>> Do not use TAC_PLUS_AUTHEN_SENDAUTH or TAC_PLUS_AUTHEN_SENDPASS >>> options. >>> >>> Use TAC_PLUS_AUTHEN_TYPE_CHAP or MS_CHAP options for authen_type >>> where possible. Use other options only when unavoidable due to >>> requirements of identity/password systems. >>> >>> Require TACACS+ authentication for authorization requests (i.e. >>> TAC_PLUS_AUTHEN_METH_TACACSPLUS is used). >>> >>> Do not use the redirection mechanism >>> (TAC_PLUS_AUTHEN_STATUS_FOLLOW). Specifically avoid the option to >>> send secret keys in the server list. >>> >>> Take case when applying extensions to the dictionary of >>> authorization/accounting arguments. Ensure that the client and >>> server use of new argument names are consistent. >> >> JC: s/client and server use of/client and server uses of/ Agreed. >> >> Joe >> Kind regards, Andrej. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
