Many thanks Alan for the thorough review. We¹ll collate all your comments and respond shortly.
On 12/10/2016 22:35, "Alan DeKok" <al...@deployingradius.com> wrote: > My $0.02 on the contents of the Security Considerations section. I'm >sure I've missed things. > > Please also comment if the suggestions here are wrong or unworkable. > >---- >9. Security Considerations > >The protocol described in this document has been in widespread use >since specified in "The Draft" (1998). However it does not meet >modern security standards, and faces vulnerabilities with privacy and >authenticity. > >This section describes issues with the TACACS+ specification, then the >protocol, deployments, followed by recommendations for implementations. > >Because of the security issues with TACACS+, the authors intend to >follow up this document with an enhanced specification of the >protocol employing modern security mechanisms. > > >9.1 Security of The Draft Specification > >TACACS+ was originally specified in "The Draft" (1998). However, this >draft is incomplete, and leaves key points unspecified. As a result, >software authors have had to make implementation choices about what >should, or should not, be done in certain situations. These >implementation choices are somewhat constrained by ad hoc >interoperability tests. That is, all TACACS+ clients and servers >interoperate, so there is a rough consensus on how the protocol works. > >While the authors have made every effort to maintain compatibility, >there is no guarantee, however, that this specification matches the >behavior of current or historical implementations. We believe that >any incompatibilites are due to modern security requirements. We >therefore suggest that implementors should read this document, and >verify that their implementations follow the security practices >recommended here. > > >9.2 Security of The Protocol > >The major security issue with the TACACS+ protocol is the ad hoc >"encryption" defined in Section 3.6. This "encryption" is more >properly called "obfuscation", and has had no security analysis. That >is, the security or insecurity of the protocol is entirely unknown. > >Attacks on cryptographic hashes are well known and are getting better >with time, as discussed in [RFC4270]. The security of the TACACS+ >protocol is dependent on MD5 [RFC1321], which has security issues as >discussed in [RFC6151]. It is not known if the issues described in >[RFC6151] apply to TACACS+. <<AD: lifted from RFC 6929 Section 11 >> > >The choice of encrypting the body but not the packet header is >unusual. The lack of security on the packet header means that an >attacker can modify the header without detection. > >For example, a "session_id" can be replaced by an alternate one, which >could allow an unprivileged administrator to "steal" the authorization >from a session for a privileged administrator. An attacker could also >update the "flags" field to indicate that one or the other end of a >connection requires TAC_PLUS_UNENCRYPTED_FLAG, which could remove what >little security is available. > >What little security that exists is dependent on implementations >limiting access to known clients, and on the strenght of the secret >key. Attacks who can guess the key or break the obfuscastion method >can gain unrestricted and undetected access to all TACACS+ traffic. >This access permits the attacker to execute any command on any system, >leaving the attacker in complete control of the network. The negative >side effects of such a successful attack cannot be overstated. > >9.2.1 Security of Authentication Sessions > >There are a number of security issues with authentication sessions. >As the sessions enable the exchange of clear-text passwords, an >attacker capable of observing the unencrypted traffic or breakign the >encrypted traffic, can gain complete network access. Similarly, >MSCHAPv1 and MS-CHAPv2 offer little additional security, while ARAP is >insecure and MUST NOT be used. As of the publication of this >document, there has been no similar attacks on the CHAP protocol. > >Section 4.4.3 permits the redirection of a session to another server >via the TAC_PLUS_AUTHEN_STATUS_FOLLOW mechanism. As part of this >process, the secret key for a new server can be sent to the client. >This public exchange of secret keys means that once one session is >broken, it may be possible to leverage that attack to attacking >connections to other servers. Section 9.4, below, has recommendations >for securing this portion of the protocol. > >9.2.2 Security of Authorization Sessions > >The primary issue with authorization sessions is that unauthenticated >authorization is allowed. Almost as bad, authorization is permitted >where authentication was done by a third party, such as with >TAC_PLUS_AUTHEN_METH_KRB5. This third party authentication is based >entirely on the client claiming that the user has been authenticated, >and the server trusting that request. This practice is entirely >insecure. > >There is also no way to cryptographically tie an authorization session >to a particular authentication session. That is, when the client >indicates "authen_method" in the packet header, the authentication and >authorization sessions are tied together implicitly by the contents of >the other fields, such as "use", "port", "rem_addr", etc. > ><<AD: it would be good for Section 5.1 to contain recommendations on >how the server can use these fields to tie together authentication / >authorization sessions. Perhaps recommend that all AAA include a >"task_id"? >> > >The specification allows for the exchange of attribute-value pairs. >While a few such attributes are defined here, the protocol is >extensible, and vendors can define their own attributes. There is no >registry for such attributes, and in the absence of a published >specification, no way for a client or server to know the meaning of a >new attribute. > >As a result, vendors SHOULD NOT define new attribute-value pairs, >unless such pairs are used only to communicate between client and >server implementations both written by the same vendor. > >The "cmd" and "cmd-arg" attributes define shell commands and >arguments, but does not specify what these are. The specific >commands, therefore, are undefined. > > >9.2.3 Security of Accounting Sessions > >The security considerations for accounting sessions are largely the >same as for authorization sessions. This section describes additional >issues specific to accounting sessions. > >There is no way in TACACS+ to signal that accounting is required. >There is no way for a server to signal a client how often accounting >is required. The accounting packets are received solely at the >clients discretion. Adding such functionality would assist with >auditing of user actions. > >The "task_id" field is defined only for accounting packets, and not >for authentication or authorization packets. As such, it is difficult >to correlate accounting data with a previous authentication or >authorization request. > ><<AD: re-use the recommendations suggested for Section 5.1, above? >> > > >9.4 Security of Deployments > >Due to the above concerns with the protocol, it is critical that it be >deployed in a secure manner. > >Systems using TACACS+ MUST be configured so that TACACS+ traffic is >secured. Any user or service who is not interacting with the TACACS+ >protocol MUST NOT be able to observe TACACS+ traffic, even when >TACACS+ "encryption" is used. > >When used inside of enterprises, TACACS+ traffic MUST be sent over >management networks. When used on the wider internet, TACACS+ traffic >MUST be secured via a modern security protocol such as TLS or IPSec. >As this specification describes the historic protocol, recommendations >on TLS and IPSec parameters are outside of the scope of this document. > > >9.4 Recommendations for Implementations > >The following recommendations are for clients and servers which >implement the TACACS+ protocol. These recommendations describe end >user interaction or user interface design. While not part of the >protocol itself, good designs can prevent insecure configurations. > >Clients and servers MUST default to rejecting all connections which >have the TAC_PLUS_UNENCRYPTED_FLAG set. Clients and servers MAY >permit such connections when a debugging or test flag is set. Clients >and servers MUST NOT run with this flag set in normal environments. > >Similarly, the default for both clients and servers MUST be to require >a secret key when configuring a new server or client. The secret key >MUST NOT be empty, and SHOULD be at least eight (8) characters in >length. Clients and servers SHOULD permit the user of keys unique to >each server or client which they are connecting to. They SHOULD warn >the administrator if a secret key is re-used. Documentation for >implementations SHOULD recommend the use of strong secret keys. > >Servers should maintain list of known clients, and reject connections >which originate from other systems. Servers SHOULD NOT permit the >configuration of wildcard clients. e.g. clients which map to a >network range. > >Where a client or server detects that the secret key is incorrect, it >SHOULD terminate the underlying TCP connection, and log a message to >the system administrator. There is no good reason to keep a >connection open when the systems are unable to communicate in a >meaningful fashion. > >Implementions MUST default to using TAC_PLUS_AUTHEN_TYPE_CHAP for >authentication. We recognize, however, that this authentication >method is incompatible with many password storage systems. As a >result, other authentication methods are still in the protocol, and >can be used so long as administrators recognize the security issues >with their use. > >Clients MUST default to treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as if >TAC_PLUS_AUTHEN_STATUS_FAIL had been received instead. Clients >SHOULD allow administrators to explicitly enable the >TAC_PLUS_AUTHEN_STATUS_FOLLOW functionality. When the functionality >is enabled, clients SHOULD permit administrators to specify ranges of >addresses, and/or sets of hosts, along with corresponding secret keys, >for which redirection will be permitted. Clients SHOULD ignore >redirects to hosts which are outside of the pre-configured range or >list. Clients SHOULD ignore any key provided via >TAC_PLUS_AUTHEN_STATUS_FOLLOW, and SHOULD instead use a preconfigured >key for that host. > >For authorization, servers SHOULD default to requiring >TAC_PLUS_AUTHEN_METH_TACACSPLUS. Servers SHOULD track authentication >sessions via methods "to be described" in Section 5.1. > >Where a server receives an unknown attribute-value pair, it SHOULD >reply with TAC_PLUS_AUTHOR_STATUS_FAIL. Where a server receives an >unrecognized values in authorization attributes such as "cmd", >"cmd-arg", "acl", etc., the server SHOULD reply with >TAC_PLUS_AUTHOR_STATUS_FAIL. When a client receives an unknown >authorization attribute, it SHOULD behave as if it had received >TAC_PLUS_AUTHOR_STATUS_FAIL. > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg