On Jul 14, 2018, at 12:57 AM, Douglas Gash (dcmgash) <dcmg...@cisco.com> 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 the previous paragraph. TACACS+ Server deployments > SHOULD ONLY use other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or > TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of > identity/password systems. > > TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in > the original draft SHOULD not be used, That's one instance where "used" is appropriate. > due to their security implications. TACACS+ server implementations SHOULD > deprecate them, if they are not deprecated, the implementations MUST default > to the options being disabled and MUST warn the user of their security impact > if they are enabled. That's good. > 9.5.4 Authorization > > The authorization and accounting features are intended to provide > extensibility and flexibility. There is a base dictionary defined in this > document, but is may be extended in deployments by using new attribute names. > The cost of the flexibility is that administrators and implementors MUST > ensure that the attribute and value pairs shared between the clients and > servers have consistent interpretation. And how is that done? The appropriate IETF answer here is "run away screaming". :( i.e. not a subject you want to touch in this draft. > If a client implementation receives receiving a mandatory authorization > attribute that its implementation does not define, then it SHOULD behave as > if it had received TAC_PLUS_AUTHOR_STATUS_FAIL. I'm wary of the word "behave" here. It seems philosophical again. I can't offer much better here tho. > TACACS+ server deployment administrators SHOULD mandate that TACACS+ > authentication was used when processing authorization requests (i.e. > authen_method value is set to TAC_PLUS_AUTHEN_METH_TACACSPLUS). Again, "mandate". Why not "administrators SHOULD configure TACACS+ authentication for processing authorization requests..." > 9.5.5 Redirection Mechanism > > The original draft described a redirection mechanism > (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to secure. The the > option to send secret keys in the server list is particularly problematic. nit: "the the". And why is it problematic? Perhaps "insecure", with an explanation as to why. > TACACS+ server implementations SHOULD deprecate the redirection mechanism. "implementations" is fine here. Perhaps also "SHOULD deprecate the redirection mechanism, and disable it by default." > TACACS+ server implementations MUST warn deployment administrators of the > security implications if the option to send the secret keys in the server > list is configured. Security implications which are...? The draft doesn't say. Perhaps just "MUST warn administrators that the option is insecure and should only be used inside of a trusted environment" > TACACS+ client implementations SHOULD deprecate this feature by treating > TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
