> On 9 Jul 2018, at 21:54, Joe Clarke <jclarke=40cisco....@dmarc.ietf.org>
> wrote:
>
> On 7/6/18 09:39, Douglas Gash (dcmgash) wrote:
>>
>> Hi,
>>
>> Below is revised version of the subsection, based upon Alan’s comments,
>>
>> Many thanks.
>
> Below are some of my comments. They mainly revolve around the strength
> of the normative language with respect to the fact that this draft is
> supported to document the protocol as it is today. To me, the security
> considerations should reflect best common practices without
> over-enforcing things that would invalidate current implementations.
>
> But I want the WG's thoughts on this. How do we handle the case where
> we have existing deployments that we want to document while at the same
> time recommending new _implementations_ do better things? And if new
> implementations should be using a new security paradigm to be described
> in a new document, do we need strong normative language in this draft?
>
> These comments are my own as a contributor.
>
>>
>>
>>
>>
>> 9.5 TACACS+ Deployment Best Practices
>>
>> In view of the observations about the security issues described above, a
>> network administrator MUST NOT rely on the
>
> Maybe "With respect to the observations..."
>
> 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.
>
> This works for me. The strong normative language makes sense here.
>>
>> 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.
>>
>> TACACS+ servers MUST NOT accept any new sessions on any connection where an
>> invalid shared secret is detected. TACACS+ servers MUST terminate the
>> connection on completion of any sessions that were previously established
>> with a valid shared secret on that connection.
>
> The MUST here seems too strong given that some implementations that are
> working today may not/may do these things. These don't seem to be
> things completely within the operator's control as they deploy T+.
I think you're right on the first and we can dilute most of MUST/MUST NOT
requirement to SHOULD/SHOULD NOT.
I would leave "server MUST only accept network connection attempts ..." as that
can be implemented outside of server (e.g. OS firewall or similar filtering
mechanisms). We could also reword this to make it clear that servers SHOULD be
able to do this (as guidance to programmers), but deployers/operators MUST find
ways to do this.
>
>>
>> 9.5.2 Shared Secrets
>>
>> TACACS+ server and client implementations MUST treat shared secrets as
>> sensitive data to be managed securely.
>
> How is this done? This seems like it could be handled in different
> ways, and making this a mandatory requirement could invalidate current
> implementations.
>
> That said, I agree that in principle this makes sense.
Would it work if we change this to SHOULD and provide some pointers to
programmers what they SHOULD think about when writing servers and clients:
things like locking memory to avoid swapping clear-text secrets, log sanitizing
- esp. device logs that merrily account/log secrets from CLI commands). This in
addition to some operational notices like MUST treat secret configs like any
other stored clear-text secret, regardless of obfuscation (e.g. "type 7"
obfuscation comes to my mind - just because it's not human readable, doesn't
mean it's not readable at all).
>
>>
>> TACACS+ server implementations MUST allow a dedicated shared secret to be
>> defined for each client. The server implementations SHOULD warn
>> administrators if secret keys are not unique per client.
>
> The MUST here again seems that it might preclude existing implementations.
Agreed.
>
>>
>> TACACS+ Server implementations MUST NOT use the TAC_PLUS_UNENCRYPTED_FLAG
>> option when processing connections from any client when a client secret has
>> been defined.
>
> I agree with this in that in seems like it would be a bug otherwise.
>
>>
>> TACACS+ server administrators SHOULD always define a shared secret for each
>> client.
>>
>> TACACS+ server administrators SHOULD use shared secrets of minimum 16
>> characters length.
>>
>> TACACS+ server administrators SHOULD change shared secrets at regular
>> intervals.
>
> These seem reasonable. They read more as recommendations.
>
>>
>> 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).
>
> Same comment as above that this may be too strong.
I think current implementations already allow for this by simple omission of
configured authentication method.
I'm more worried that this may not be a useful statement anyway as I haven't
encountered a device in wild that would actually use any of the CHAP
authentication methods. We ask implementors to implement something that's not
actually used/useful in the wild ... I have some doubts about it.
The plan behind this verbiage was to push/nudge vendors towards adding support
for CHAP by virtue of pointing to the RFC and asking them to comply. But like
you noted, this may be overstepping the mandate of informational RFC draft.
>
>>
>> TACACS+ server deployments SHOULD use 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, due to their security implications.
>>
>> 9.5.4 Authorization
>>
>> The authorization and accounting features are intended to provide extensible
>> 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.
>>
>> 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.
>>
>> TACACS+ server deployments SHOULD mandate that TACACS+ authentication was
>> used when processing authorization requests (i.e. authen_method value is set
>> to TAC_PLUS_AUTHEN_METH_TACACSPLUS).
>>
>> 9.5.5 Redirection Mechanism
>>
>> The original draft described a redirection mechanism
>> (TAC_PLUS_AUTHEN_STATUS_FOLLOW). This feature is difficult to secure. The
>> option to send secret keys in the server list is particularly problematic.
>>
>> TACACS+ server implementations SHOULD deprecate the redirection mechanism.
>>
>> TACACS+ server implementations MUST warn users of the security implications
>> if the option to send the secret keys in the server list is configured.
>
> Same comment here.
>
>>
>> TACACS+ client implementations SHOULD deprecate this feature by treating
>> TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.
>
> So, again, strong normative language makes sense if I'm building a new
> implementation, but this is a doc to define the protocol as-is. In
> light of that, I am asking the WG if we need to go down this path or
> should we try and focus on recommendations, especially for operators,
> that can better secure the T+ they have today.
As one of the authors (and we're not single-minded collective, so others may
disagree) I think we went overboard with what we would wish the end state would
be and it shows. It would be great if WG would allow this kind of strong
verbiage to remain, but only if majority feels that there's a real benefit to
it and that it doesn't stretch what informational RFC is allowed to be.
Focusing more on operational concerns certainly sounds like a pragmatic and
better way to both document the protocol as is and provide operators (but not
programmers) with information that helps them deploy it in a safer manner.
Andrej Ota.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
