Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
Thanks Alan… On 14/07/2018, 15:00, "Alan DeKok" wrote: On Jul 14, 2018, at 12:57 AM, Douglas Gash (dcmgash) wrote: > > Dear Alan, > > Do the changes below clarify the intent sufficiently? (please find diff below) The changes are mainly in first section with a few tweaks in later sections. Let's see... > 9.5 Deployment Best Practices > > With respect to the observations about the security issues described above, a network administrator MUST NOT rely on the obfuscation of the TACACS+ protocol and TACACS+ MUST be deployed over networks which ensure privacy and integrity of the communication. TACACS+ MUST be used within a secure deployment. Failure to do so may impact overall network security. Again "may" is simply not true. It WILL impact network security. Updated > The following recommendations impose restrictions on how the protocol is applied. > > The document identifies two constituencies: implementors of TACACS+ components (servers and clients), and administrators of TACACS+ deployments in the field. The document assumes that it will only be read by the implementors. That's a problem. As I've been saying for a while now, in many messages, the document must give guidance for people implementing *and* deploying the protocol. Well, I had aligned based upon an earlier comment that we had received for the draft: “Configure Server to reject connections which have the TAC_PLUS_UNENCRYPTED_FLAG. Servers SHOULD allow administrators to reject those packets with applicable ERROR response for type of packet. Consequently, clients should avoid using TAC_PLUS_UNENCRYPTED_FLAG, even on networks with secured transport. In summary: do not use the TAC_PLUS_UNENCRYPTED_FLAG option.” The comment was: “Is this "configure" a requirement on administrators? Do administrators have to read the RFCs in order to configure the systems correctly?” I believe that we want to assign the implementors mandatory actions so that the administrators do not have to read the RFC. But for now, I will drop the paragraph. > Mandatory actions are therefore assigned to implementors to either deprecate insecure features or to steer the administrators to the practices they should adopt by defaulting to the recommended options and warning when the restrictions are not adopted. That sentence follows from the previous mistake. It's also wrong. It's sufficient to just say "implementors must/should do A, B, and C. Deployments must/should do D, E, and F". It's not necessary to describe what the specification is for, or how specifications are written. The para is removed. > Some of the specific requirements mandated for TACACS+ servers and TACACS+ clients may not be present in currently deployed implementations. New implementations, and upgrades of current implementations, MUST implement the recommendations. > > 9.5.1 Server Side Connections > > TACACS+ server implementations MUST allow the definition of individual clients, and the servers MUST only accept network connection attempts from these defined, known clients. There's no need to keep saying "server implementations". The requirement is on servers, and it's sufficient to say that. *TACACS+ servers MUST allow... * Sure. > If an invalid shared secret is detected on a connection, TACACS+ server implementations MUST NOT accept any new sessions on that connection. TACACS+ servers MUST terminate the connection on completion of any sessions that were previously established with a valid shared secret on that connection. > > When a client secret is defined, TACACS+ Server implementations MUST not use the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that client. What does it mean to "use" that flag? And what about "processing connections"? This is all vague and non-technical. These are issues I've commented on for a *long* time now. I would have hoped for progress here. A better phrasing is: *When a client secret is defined, TACACS+ servers MUST NOT accept connections from that client which have the TAC_PLUS_UNENCRYPTED_FLAG option set.* Will adjust along those lines. How do they do that? It doesn't matter. The spec requires security, and it's up to whomever (implementation or deployment) to make that happen. > 9.5.2 Shared Secrets > > TACACS+ Server and client implementations MUST treat secrets as sensitive data to be managed securely. > > TACACS+ Server implementations MUST allow a dedicated secret key to be defined for each client, and the servers SHOULD warn administrators if secret keys are not unique per client. > > TACACS+ server deployment administrators SHOULD always define a secret for each client. > > TACACS+ server deployment
Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor
On Jul 14, 2018, at 12:57 AM, Douglas Gash (dcmgash) wrote: > > Dear Alan, > > Do the changes below clarify the intent sufficiently? (please find diff > below) The changes are mainly in first section with a few tweaks in later > sections. Let's see... > 9.5 Deployment Best Practices > > With respect to the observations about the security issues described above, a > network administrator MUST NOT rely on the obfuscation of the TACACS+ > protocol and TACACS+ MUST be deployed over networks which ensure privacy and > integrity of the communication. TACACS+ MUST be used within a secure > deployment. Failure to do so may impact overall network security. Again "may" is simply not true. It WILL impact network security. > The following recommendations impose restrictions on how the protocol is > applied. > > The document identifies two constituencies: implementors of TACACS+ > components (servers and clients), and administrators of TACACS+ deployments > in the field. The document assumes that it will only be read by the > implementors. That's a problem. As I've been saying for a while now, in many messages, the document must give guidance for people implementing *and* deploying the protocol. > Mandatory actions are therefore assigned to implementors to either deprecate > insecure features or to steer the administrators to the practices they should > adopt by defaulting to the recommended options and warning when the > restrictions are not adopted. That sentence follows from the previous mistake. It's also wrong. It's sufficient to just say "implementors must/should do A, B, and C. Deployments must/should do D, E, and F". It's not necessary to describe what the specification is for, or how specifications are written. > Some of the specific requirements mandated for TACACS+ servers and TACACS+ > clients may not be present in currently deployed implementations. New > implementations, and upgrades of current implementations, MUST implement the > recommendations. > > 9.5.1 Server Side Connections > > TACACS+ server implementations MUST allow the definition of individual > clients, and the servers MUST only accept network connection attempts from > these defined, known clients. There's no need to keep saying "server implementations". The requirement is on servers, and it's sufficient to say that. *TACACS+ servers MUST allow... * > If an invalid shared secret is detected on a connection, TACACS+ server > implementations MUST NOT accept any new sessions on that connection. TACACS+ > servers MUST terminate the connection on completion of any sessions that were > previously established with a valid shared secret on that connection. > > When a client secret is defined, TACACS+ Server implementations MUST not use > the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that > client. What does it mean to "use" that flag? And what about "processing connections"? This is all vague and non-technical. These are issues I've commented on for a *long* time now. I would have hoped for progress here. A better phrasing is: *When a client secret is defined, TACACS+ servers MUST NOT accept connections from that client which have the TAC_PLUS_UNENCRYPTED_FLAG option set.* How do they do that? It doesn't matter. The spec requires security, and it's up to whomever (implementation or deployment) to make that happen. > 9.5.2 Shared Secrets > > TACACS+ Server and client implementations MUST treat secrets as sensitive > data to be managed securely. > > TACACS+ Server implementations MUST allow a dedicated secret key to be > defined for each client, and the servers SHOULD warn administrators if secret > keys are not unique per client. > > TACACS+ server deployment administrators SHOULD always define a secret for > each client. > > TACACS+ server deployment administrators SHOULD use secret keys of minimum 16 > characters length. > > TACACS+ server deployment administrators SHOULD change secret keys at regular > intervals. That's all good. It's OK to talk specifically about implementation and deployments when the requirements are on implementation internals, or on managing a deployment. > 9.5.3 Authentication > > TACACS+ server implementations MUST allow the administrator to mandate that > only challenge/response options will be accepted for authentication > (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or > TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type). NIT: I would sat "allow the administrator to configure that" Again, "mandate" is philosophical. Administrators "configure" implementations. They don't "mandate" implementations. > TACACS+ server deployment administrators SHOULD use "configure". Not "use". I "use" a pencil. I "configure" an implementation. TBH, you should audit the document for instances of "use", and replace them with something more appropriate. > the option mentioned in
