Subject: Re: [OPSAWG] TACACS+ information Draft Security Recommendations refactor

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Fri, 6 Jul 2018 13:39:33 +0000

Hi,

Below is revised version of the subsection, based upon Alan’s comments,

Many thanks.

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 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.
 
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.
 
9.5.2 Shared Secrets
 
TACACS+ server and client implementations MUST treat shared secrets as sensitive data to be managed securely.
 
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.
 
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.
 
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.
 
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).
 
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.
 
TACACS+ client implementations SHOULD deprecate this feature by treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.

On 28/06/2018, 17:23, "Douglas Gash (dcmgash)" <[email-masked]> wrote:

    Hi Alan,
    
    Thank you for the response. Please see responses below.
    
    On 28/06/2018, 14:22, "Alan DeKok" <[email-masked]> wrote:
    
        On Jun 28, 2018, at 2:03 AM, Douglas Gash (dcmgash) <dcmgash=[email-masked]> wrote:
        > 
        > Dear Opsawg,
        > 
        > The TACACS+ Draft Version 9 contains a security section, the last three subsections of which are recommendations. There is some overlap and repetition between sections where the same issues are covered from different angles, which we believe may lead to ambiguity.
        > 
        > So instead we propose to refactor the recommendations section to bring recommendation points of each aspect into their own subsections, as below. 
        
          There are common requirements for client-server connections.  However, there are different security requirements for clients and servers.  Even the new text you propose below makes this clear.
        
          I think that merging such text into one section makes the requirements less clear.
    
    I can see what you mean, especially in the Client-Server connection subsection. I propose to split this subsection in view of your comments. 

        > Please note that this section is within the context of the security section, where the security vulnerabilities are discussed in sections 9.1-9.4.
        
          The new text has many long sentences, and a generally "conversational" feel.  i.e. it's not simple, short, and technical.
    
    That is a fair comment. The intent was to provide a “Because of X, then do Y” pattern, but it does result in an overly dialectic result. We will refactor to provide more focus on the “do Y” part, but look to enhance the detail of the Y.

        > This new model should replace sections 9.5-9.7.
        > 
        > Many thanks.
        > 
        > Proposed recommendations section follows:
        > 
        > 
        > 
        > 9.5 Deployment Best Practices
        > 
        > In view of the observations about the security issues described above, it is critical that TACACS+ MUST BE deployed over secure networks which ensure an appropriate level of privacy and integrity of the communication.
        
          I'm not sure "appropriate" is the nest word here.  It's vague, non-technical, and entirely unhelpful to the reader.  In contrast, the earlier text was clearer:
        
    Agreed. It will be removed.

              TACACS+ MUST BE employed over networks which ensure privacy and
              integrity of the communication. 
        
          I find that the draft has gone *backwards* here, by removing technical and descriptive text.
        
        > Two methods are used in common practice. The preferred method, where such a facility is available in the organization, is to use a dedicated secure management network. Where this is not available, it is recommended to use IPSec.
        > 
        > In summary: It is strongly advised that TACACS+ MUST be used within a secure deployment.  Failure to do so may impact overall network security.
        
          "strongly advised that you MUST do something" ?
        
          This statement is contradictory and unclear.
    
    Agreed. Propose to distill to: “In summary: TACACS+ MUST be used within a secure deployment.  Failure to do so may impact overall network security.”
        
        > 9.5.1 Client-Server Connections
        > 
        > In order to help administrators to protect against brute-force attacks from unknown clients, TACACS+ Servers MUST allow the definition of individual clients and MUST allow a dedicated secret key to be defined for each client.
        
          How does defining individual clients or secrets protect against "brute-force" attacks?  Is this not just listing known clients, and rejecting connections from unknown clients?
        
    To be fair the claim is caveated to say  to protect against "brute-force attacks from unknown clients", but I do agree that as you say, it does mean simply rejecting from unknown clients. Another example of “Because of X, then do Y”. We will refocus this to the “do Y” part, but include the part about unknown clients”.

          The earlier text was clearer:
        
              Servers MUST be configured with a list of known clients.  Servers
              MUST be configured to reject requests from clients not on the
              list.  A unique secret key SHOULD be configured for every
              individual client.
        
        > With these mandatory requirements in place, the following recommendations should be followed:
        > 
        > Configure Servers to accept only those network connection attempts that arrive from known clients.  This limits the exposure and prevents remote brute force attacks from unknown clients.
        
          Is this "configure" a requirement on implementors or administrators?  And why not use mandatory language here, as was used in draft-06?  The current text is not very prescriptive.
    
    The intent overall is: Implement this so that administrators can configure that. But the whole section needs to be taken together to implicitly deduce this, I take the point that a little extra text will make each part of the section more explicitly clear.
        
        > Configure a secret key on the server for each client. It is recommended that Servers SHOULD warn administrators if secret keys are not unique per client.
        
          "it is recommended" is redundant with "SHOULD"
    
    Agreed.

        > 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.
        
          Is this "configure" a requirement on administrators?  Do administrators have to read the RFCs in order to configure the systems correctly?
    
    It is a valid point. I think it is fair to say the implementations SHOULD indicate that administrators SHOULD not configure the unencrypted option. I don’t think that either of the two SHOULDs should be a M UST, but possibly the first could be.
        
          Or should implementors make the software do this by default?
    
    I’m not sure we can do that, because it would require a default secret, and that would contravene most security analysis for an implementation. But would welcome proposals.
        
          And the redundancy continues:  " clients should avoid using " .. "In summary: do not use "
        
    Agreed.
    
          The text is vague, rambling, and redundant.
    
    Will remove the redundancy.
        
        > The strongest authentication options in the TACACS+ protocol are the challenge-response options (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type). Consequently, The Server implementation MUST allow the administrator to mandate that only these challenge/response options will be accepted for authentication. 
        > 
        > It is recommended that administrators use this option. Administrators should allow other options only when unavoidable due to requirements of identity/password systems.
        
          Is there prescriptive text here instead of "it is recommended"?  Maybe SHOULD ?
    
    Agreed.
        
        > Due to their security implications, the TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft should not be used. 
        
          Maybe "MUST NOT be used" ?
    
    I would agree to it, but we may need wider consensus. Do we have any options between MUST and SHOULD ;-)

        > 9.5.4 Authorization Options
        > 
        > 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 MUST ensure that the attribute and value pairs shared between the clients and servers have consistent interpretation. 
        > 
        > If a client 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.
        > 
        > Require TACACS+ authentication for authorization requests (i.e. TAC_PLUS_AUTHEN_METH_TACACSPLUS is used).
        
          That last sentence seems unfinished.
    
    Agreed. The sentence has dropped a subject, will re-install one.
        
        > 9.5.5 The Redirection Mechanism
        > 
        > The redirection mechanism (TAC_PLUS_AUTHEN_STATUS_FOLLOW) that was defined in the original draft is difficult to secure. It is recommended to disable the feature, and so to avoid its use altogether. It is recommended that clients treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. 
        
          Is there prescriptive text here instead of "it is recommended"?  Earlier text had such prescriptive text.
    
    Agreed, I will add the prescriptive text to be consistent with the body of the document.
        
        > If the option must be used for legacy application reasons, then it is recommended to avoid the option to send secret keys in the server list.
        
          Again, "it is recommended"
        
          The new text is a step backwards from earlier drafts.  I've taken a look at the rest of Section 9, and it's similar.
    
          As an implementor, this text gives me only vague guidance as to what to do.  With less clarity and fewer prescriptions than earlier text.
        
          I've said before that the text is philosophical and conversational instead of technical.  This style is continuing with new text.
        
    The other parts of section 9 will be addressed in another thread, but both they and this section will be addressed with your comments as above ASAP.

          Alan DeKok.

---

From: Joe Clarke <[email-masked]>
Date: Mon, 9 Jul 2018 16:54:45 -0400

> Below is revised version of the subsection, based upon Alan’s comments,

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.

> 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.

> 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…

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+.

> 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.

> 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.

> 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 change shared secrets at regular intervals.

These seem reasonable.  They read more as recommendations.

> 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_MS…

Same comment as above that this may be too strong.

> 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.

Joe

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 9 Jul 2018 17:11:48 -0400

> over-enforcing things that would invalidate current implementations.

  I think that the security considerations section *should* invalidate insecure implementations.

> time recommending new _implementations_ do better things?

  We recommend that *all* implementations do the Right Thing.

  If an admin installs a product released before the recommendations, then it clearly won't comply.  That's life, and there isn't much we can do about it.

  But there's just no reason to allow new releases to ignore modern security practices.

>  And if new

  Yes.

> things completely within the operator's control as they deploy T+.

  These implementations are written before modern security practices.  We can't invalidate software that's already written and running in the wild.

  We *can* recommend that vendors && admins have the best possible security in the products they ship and use.

> How is this done?

  "implementation specific". :(

>  This seems like it could be handled in different

  One word: upgrade.

> implementation, but this is a doc to define the protocol as-is.

  And, to describe how to *use* the protocol as securely as possible, given it's limitations.

>  In

  I think that if the WG punts on security, the security area directorate will punt the document back to the WG.  And say "fix it".

  This isn't about invalidating current implementations.  It's about telling people that *new* implementations, or new *releases*, have to be as secure as possible.

  If the WG punts on security then we might as well add a note to the document saying "using this protocol will ensure that hackers will pwn your equipment".  Because it will be absolutely true.

  And then *no one* will want to implement it.

  Alan DeKok.

---

From: Joe Clarke <[email-masked]>
Date: Mon, 9 Jul 2018 17:36:23 -0400

>   And then *no one* will want to implement it.

I hear and understand what you're saying.  And if this were a net new
protocol, I'd agree with you 100%.  But the mandate for this document is
to describe how T+ is implemented today[1].  Today, people are deploying
it with all sorts of security issues because that's how the protocol works.

Maybe they are trying to do it as securely as they think is possible,
and that's good.  But there's only so much they can do within the scope
of the protocol as it exists today.  To _that_ end, I strongly feel we
_must_ provide clear guidelines to help implement T+ as securely as is
possible.  But people need to be aware that until a better security
model is created, those steps are limited.

On top of that, new implementations that change behavior could be
incompatible with existing clients.

[1] As I recall, the ultimate goal of the work was to be able to add
modern security to T+.  Before that could happen, the WG agreed that T+
should be documented -- in an informational document -- to set context.
Simply documenting that this protocol is insecure, good luck and
goodnight was not desirable, so a more robust security considerations
was crafted mainly driven by your work, Alan.  And to the extent that
operators can help themselves with securing what they have, I'm all for it.

As a new _implementor_ of a server, I'd rather not repeat the protocol
flaws of the past if a new security model is coming (i.e., within a new
draft).  So my thinking is that we recommend what we can for deployment.
 Will Sec AD accept this?  I don't know.  I don't know that they've been
asked.

What I can do is request an early review from SEC-DIR to specifically
get their expert review on the security section.

Joe

---

From: Andrej Ota <[email-masked]>
Date: Mon, 9 Jul 2018 22:37:52 +0100

> On 9 Jul 2018, at 21:54, Joe Clarke <jclarke=[email-masked]> wrote:
> 

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.

> 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).

Agreed.

> 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.

> 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.

---

From: Andrej Ota <[email-masked]>
Date: Mon, 9 Jul 2018 22:51:32 +0100

> On 9 Jul 2018, at 22:11, Alan DeKok <[email-masked]> wrote:
> 

I think that on a protocol level there isn't even a single implementation that would make protocol even remotely secure as such and one cannot be made without significantly altering the protocol. In my eyes, the problem is akin to asking what can be done to make HTTP secure and the answer was unanimously to use secure transport (i.e. SSL at first and now TLS), though, supposedly, DIGEST HTTP authentication method would solve the problem of leaking passwords while leaving CC numbers in the open.

Is it worth asking everyone or even expecting anyone to migrate to new-improved-and-still-insecure revision of T+ that requires exactly same amount of operational solutions to secure deployment?

Andrej.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 9 Jul 2018 21:59:28 +0000

> it with all sorts of security issues because that's how the protocol works.
    
I think Alan got it right. You are describing an existing protocol. Fine.  

It still is your responsibility to state what are the security properties it provides *according to the current understanding of what the security posture should be* (because you are documenting *now* what had been done back then), regardless of whether the original designers and/or implementers gave a hoot about them or not.

And if the answer is "it has no security worth mentioning", tough luck - you still MUST state that. Since it is an existing protocol rather than a new design, IESG would probably let it slide.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 9 Jul 2018 20:50:55 -0400

On Jul 9, 2018, at 5:36 PM, Joe Clarke <[email-masked]> wrote:
> to describe how T+ is implemented today[1].

 So...

a) we rubber-stamp existing practices and implementations, no matter how insecure

  or

b) we describe the protocol, along with recommendations for how best to secure it.

  I think that (b) is the best approach.  I don't understand why we would ever choose (a).

>  Today, people are deploying

  Perhaps the IETF could give guidance on best practices?  Along with what parts of the protocol are insecure, and should be avoided?

> incompatible with existing clients.

  If those existing clients are insecure and allow people to pwn your network, then I don't really have any sympathy.

  And as always, vendors are free to ignore the recommendations of the specification.  But at least after the admin gets pwned, he can point to the spec and say "YOU KNEW.  IT'S YOUR FAULT."

  The alternative is to tell the admins "We knew, but we didn't care."  That's not acceptable.

> Will Sec AD accept this?  I don't know.  I don't know that they've been

  I've been on secdir for a long time now, and have seen hundreds of reviews.  If the WG punts on security, secdir will punt the draft back to the WG with a comment of "you can do better."

  I'm here *as* the early secdir review.

  Look, I can go away and stop fighting this issue.  You'll spend 2 years updating the draft.  Which will then get punted by secdir.  And you'll be back in the same place you are today.

  Again, it looks VERY much to me like the goal is to publish an "IETF stamped" version of TACACS+.  And that the content of the document is almost irrelevant.  That's just not how this works.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 9 Jul 2018 20:58:09 -0400

> Is it worth asking everyone or even expecting anyone to migrate to new-improved-and-still-insecure revision of T+ that requires exactly same amount of operational solutions to secure deployment?

  Is anyone asking for that?

  No?

  Then why bring it up?  It's a straw man.

  As a case in point, there are RADIUS "best practices" documents from 10 years ago that vendors still ignore.  That's their right.  The IETF isn't about requiring or mandating that anyone do anything.

  It's about allowing people to make informed decisions.

  Which means recommending best practices.  It means recommending how best to deploy TACACS+... legacy.  Even if there's no "better" version of TACACS+ yet available.

  There is no desire to "invalidate" current implementations.  The desire is to *recommend* best practices for new deployments.  This shouldn't be the least bit controversial.

  Alan DeKok.

---

From: Andrej Ota <[email-masked]>
Date: Tue, 10 Jul 2018 08:59:18 +0100

>    Then why bring it up?  It's a straw man.

This was my understanding of the statement: "I think that the security 
considerations section *should* invalidate insecure implementations."

Andrej.

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Fri, 13 Jul 2018 04:50:28 +0000

Hi Joe,

Thanks for the comments. We will be sending out a new version of the recommendations section today. It actually intends to clarify in the first section how the guidance should be interpreted, which I think should allow our strong recommendations to be kept, as I hope it will answer your question on current implmentations,

On 09/07/2018, 23:55, "Joe Clarke" <jclarke=[email-masked]> wrote:

    

    

    

This is about the implementation, I will clarify it.

    

    

    

    
    
    Same comment here.

    
    Joe

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Fri, 13 Jul 2018 05:00:17 +0000

Dear OPSAWG,

Below is a revised version of the recommendations. I have understood the consensus to be, that we should keep the strength of the recommendations, but explain how these should be applies in the real world with many, potentially very old implementations in place.

Consequently, pretty much the only changes are in the first section. Please let us know if this matches the consensus intent.

Many thanks,

Regards,

Doug.

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.

The following recommendations are not part of the definition of the protocol. Rather, they impose restrictions on how the protocol is applied. Specific requirements of the TACACS+ server and TACACS+ client implementations are mandated to make it easier for the administrators who deploy TACACS+ to adopt the restrictions.

Some of the specific requirements mandated for TACACS+ servers and TACACS+ clients may not be present in currently deployed implementations. This is accepted as situational fact, and these implementations may still be regarded as correctly implementing the TACACS+ protocol as long as they conform to the details in other sections of this document. New implementations, and upgrades of current implementations, SHOULD implement the recommendations.

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.

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.

When a client secret is defined, TACACS+ Server implementations MUST not use the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that client.

TACACS+ server deployments SHOULD always define a secret for each client.

TACACS+ server deployments SHOULD use secret keys of minimum 16 characters length.

TACACS+ server deployments SHOULD change secret keys at regular intervals.

9.5.3 Authentication

9.5.4 Authorization

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.

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.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Jul 2018 07:30:16 -0400

> 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 networ…

  "may"?  It's much stronger than that.  Secrets will leak, people will be able to spoof credentials, etc.  It *will* impact network security.  Severely.

> The following recommendations are not part of the definition of the protocol. Rather, they impose restrictions on how the protocol is applied. Specific requirements of the TACACS+ server and TACACS…

  That last sentence is unclear to me.  And mandates don't make it easier, they make it harder.  But the mandates are necessary for security.

> Some of the specific requirements mandated for TACACS+ servers and TACACS+ clients may not be present in currently deployed implementations. This is accepted as situational fact, and these implementations may still be regarded as correctly implementing the TACACS+ protocol as long as they conform to the details in other sections of this document.

  The spec doesn't need to say "yes, all existing implementations are OK".

  This list has had long discussions on that topic, which I suspect was due to general unfamiliarity with the IETF process.  I don't think it's necessary to put that statement in the document.  

  There have been many, many, historical protocols documented in the IETF.  None that I recall have a statement explicitly blessing existing implementations.

  The document *should* say that it documents TACACS+ as per existing implementation and practice.  BUT for security reasons, certain parts of the protocol and/or deployment practices are deprecated for security reasons.

> New implementations, and upgrades of current implementations, SHOULD implement the recommendations.

  And that SHOULD means "you don't really need to adopt the recommendations".

  The spec needs to say "you MUST implement and deploy it in a secure manner".

  Alan DeKok.

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Fri, 13 Jul 2018 12:30:36 +0000

Thanks Alan...

> On 13 Jul 2018, at 14:30, Alan DeKok <[email-masked]> wrote:
> 

Agreed, will update.

>  That last sentence is unclear to me.  And mandates don't make it easier, they make it harder.  But the mandates are necessary for security.
The intent is this: the implementors of the Servers and Clients receive the new mandatory MUST items in order to make it easier for the admins deploying TACACS+ to do the stipulated SHOULD items in the field. I think we can establish that shared responsibility for the recommended security practices. That is the intent of the sentence, I will clarify it... though would welcome thoughts on that intent.

>  The spec needs to say "you MUST implement and deploy it in a secure manner".
That is reasonable and rereading last weeks comments aligns better, I will update to that effect.

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jul 2018 10:29:31 -0400

as one of the many folk who have been using this protocol since the
'90s, i gotta wonder how many angels we can sit on the head of this
bikeshed.

i do not think we are gonna 'fix' the security model.  this is a widely
deployed antique we are just trying to document so new victims can
interoperate.

i am a little slow, so would appreciate if someone could make a simple
enumertion of the substantive issues so we can tick them off, instead of
ticking me off, and get this puppy the heck out the door?

randy

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Jul 2018 10:35:09 -0400

> deployed antique we are just trying to document so new victims can

  That has been the goal all along.  Along with the goal of documenting security issues.

> ticking me off, and get this puppy the heck out the door?

  I think the current proposals are pretty close, at least from my end.  I think it's just word smithing from now on.

  Alan DeKok.

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jul 2018 10:37:03 -0400

> I think the current proposals are pretty close, at least from my end.
> I think it's just word smithing from now on.

good.  so it should be fiished by the time the drafts door re-opens on
monday?

randy

---

From: Joe Clarke <[email-masked]>
Date: Fri, 13 Jul 2018 11:30:58 -0400

> good.  so it should be fiished by the time the drafts door re-opens on

I am hoping to start a WGLC at the Tuesday meeting, and cary it over to
the list to make it official.

Joe

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jul 2018 11:36:19 -0400

> the list to make it official.

wfm.  i will read any diff so i can useffully responnd to the wglc

randy

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Jul 2018 11:36:59 -0400

> the list to make it official.

  There are still unaddressed comments.  Do we do WG last calls for unfinished documents?

  Also, we have *no idea* if the document matches current implementations or deployments.  The proponents of TACACS+ have been surprisingly silent on this topic.

  So everyone wants the document published, but they're unwilling to state if it actually documents TACACS+.

  That's a pretty large red flag *against* publication, IMHO.

  Alan DeKok.

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jul 2018 11:39:20 -0400

>   That's a pretty large red flag *against* publication, IMHO.

i am missig the example of where it does not.

randy

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Jul 2018 11:46:46 -0400

> i am missig the example of where it does not.

  There are probably dozens of implementations of TACACS+ around.  From my recollection, there may have been two implementors who said "yes the draft matches the implementation".

  And one of those was from my team.  Which was a recent implementation.

  Alan DeKok.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 13 Jul 2018 09:25:59 -0700

On 7/13/18 4:30 AM, Alan DeKok wrote:

<snip>
>   The document *should* say that it documents TACACS+ as per existing implementation and practice.  BUT for security reasons, certain parts of the protocol and/or deployment practices are deprecate…
Yeah, I think it's quite fair to say that in many cases the existing way
things have run may not be sufficient / adequate. Doing so is providing
advice to both future and current operators.

As someone who has to explain to the auditors once or twice a year how
the network access controls work, providing guidance on what is
considered adequate feeds into how people implement and think about
their management systems.

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Sat, 14 Jul 2018 04:57:12 +0000

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.

Many thanks.

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. 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.

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.2 Shared Secrets

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.

9.5.3 Authentication

TACACS+ server deployment administrators 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. 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.

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. 

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).

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.

Diff from previous version:

5c5
< The following recommendations are not part of the definition of the protocol. Rather, they impose restrictions on how the protocol is applied. Specific requirements of the TACACS+ server and TACACS+ client implementations are mandated to make it easier for the administrators who deploy TACACS+ to adopt the restrictions.
---
> The following recommendations impose restrictions on how the protocol is applied. 
7c7,9
< Some of the specific requirements mandated for TACACS+ servers and TACACS+ clients may not be present in currently deployed implementations. This is accepted as situational fact, and these implementations may still be regarded as correctly implementing the TACACS+ protocol as long as they conform to the details in other sections of this document. New implementations, and upgrades of current implementations, SHOULD implement the recommendations.
---
> 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. 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.
> 
> 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.
14a17,18
> When a client secret is defined, TACACS+ Server implementations MUST not use the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that client.
21,23c25
< When a client secret is defined, TACACS+ Server implementations MUST not use the TAC_PLUS_UNENCRYPTED_FLAG option when processing connections from that client.
< 
< TACACS+ server deployments SHOULD always define a secret for each client.
---
> TACACS+ server deployment administrators SHOULD always define a secret for each client.
25c27
< TACACS+ server deployments SHOULD use secret keys of minimum 16 characters length.
---
> TACACS+ server deployment administrators SHOULD use secret keys of minimum 16 characters length.
27c29
< TACACS+ server deployments SHOULD change secret keys at regular intervals.
---
> TACACS+ server deployment administrators SHOULD change secret keys at regular intervals.
33c35
< 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.
---
> TACACS+ server deployment administrators 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.
35c37
< TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft SHOULD not be used, due to their security implications.
---
> TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft SHOULD not be used, 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.
39c41
< 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.
---
> 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. 
43c45
< 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).
---
> 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).
49c51,58
< TACACS+ Server implementations SHOULD deprecate the redirection mechanism.
---
> 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.
> 
51c60
< TACACS+ Server implementations MUST warn users of the security implications if the option to send the secret keys in the server list is configured.
---
53d61
< TACACS+ client implementations SHOULD deprecate this feature by treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 Jul 2018 08:00:38 -0400

> 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...

> 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 networ…

  Again "may" is simply not true.  It WILL impact network security.

> 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.

> 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... *

> 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.

> 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.

> 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_MS…

  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.

> 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…

  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_TACACSPL…

  Again, "mandate".

  Why not "administrators SHOULD configure TACACS+ authentication for processing authorization requests..."

> 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 prob…

  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"

  Alan DeKok.

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Sat, 14 Jul 2018 15:38:43 +0000

Thanks Alan…

On 14/07/2018, 15:00, "Alan DeKok" <[email-masked]> wrote:

      Let's see...

Updated

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.

    

The para is removed.

    

Sure.

    

Will adjust along those lines.

    

    

Sure.

    

    
    
      That's good.

    

“Behave” may lead to adoption n of BDD in T+ clients! I was initially going to suggest “process the connection as if”, before comment above… so maybe just change “behave” to “evaluate server response…”

      Again, "mandate".

    
      nit: "the the".

Will fix.

    

    
    
    > TACACS+ client implementations SHOULD deprecate this feature by treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. 
    
Sounds reasonable.
      
      Alan DeKok.

Thanks.

Please see version with revisions below:

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 will impact overall network security.

The following recommendations impose restrictions on how the protocol is applied. These restrictions were not imposed in the original draft. New implementations, and upgrades of current implementations, MUST implement the recommendations.

TACACS+ servers MUST allow the definition of individual clients. The servers MUST only accept network connection attempts from these defined, known clients.

If an invalid shared secret is detected on a connection, TACACS+ servers 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.

9.5.2 Shared Secrets

TACACS+ servers and client MUST treat secrets as sensitive data to be managed securely.

TACACS+ servers MUST allow a dedicated secret key to be defined for each client, 

TACACS+ servers MUST reject connections with TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on the server for the client requesting the connection.

TACACS+ servers SHOULD warn administrators if secret keys are not unique per client.

TACACS+ server deployment administrators SHOULD configure secret keys of minimum 16 characters length.

9.5.3 Authentication

TACACS+ servers MUST allow the administrator to configure the server to only accept challenge/response options for authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type).

TACACS+ server deployment administrators SHOULD enable the option mentioned in the previous paragraph. TACACS+ Server deployments SHOULD ONLY enable 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. TACACS+ servers SHOULD deprecate them. If they are not deprecated, the servers MUST default to the options being disabled and MUST warn the administrator that these options are not secure.

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 it 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 receives a mandatory authorization attribute that its implementation does not define, then it SHOULD evaluate server response as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL.

TACACS+ server deployment administrators SHOULD configure the server to reject authorization requests if authen_method value is not set to TAC_PLUS_AUTHEN_METH_TACACSPLUS.

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 insecure, as it can reveal client shared secrets.

TACACS+ servers SHOULD deprecate the redirection mechanism.

If the redirection mechanism is implemented then TACACS+ servers MUST disable it by default, and MUST warn deployment administrators that it must only be enabled within a secure deployment due to the risks of revealing shared secrets.

TACACS+ clients SHOULD deprecate this feature by treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL. 

Diff as follows.

3c3
< 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.
---
> 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 will impact overall network security.
5,9c5
< 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. 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.
< 
< 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.
---
> The following recommendations impose restrictions on how the protocol is applied. These restrictions were not imposed in the original draft. New implementations, and upgrades of current implementations, MUST implement the recommendations.
13,15c9
< TACACS+ server implementations MUST allow the definition of individual clients, and the servers MUST only accept network connection attempts from these defined, known clients.
< 
< 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.
---
> TACACS+ servers MUST allow the definition of individual clients. The servers MUST only accept network connection attempts from these defined, known clients.
17c11
> If an invalid shared secret is detected on a connection, TACACS+ servers 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.
21c15,19
< TACACS+ Server and client implementations MUST treat secrets as sensitive data to be managed securely.
---
> TACACS+ servers and client MUST treat secrets as sensitive data to be managed securely.
> 
> TACACS+ servers MUST allow a dedicated secret key to be defined for each client, 
> 
> TACACS+ servers MUST reject connections with TAC_PLUS_UNENCRYPTED_FLAG set, when there is a shared secret set on the server for the client requesting the connection.
23c21
< 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+ servers SHOULD warn administrators if secret keys are not unique per client.
27c25
< TACACS+ server deployment administrators SHOULD use secret keys of minimum 16 characters length.
---
> TACACS+ server deployment administrators SHOULD configure secret keys of minimum 16 characters length.
33c31
< 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).
---
> TACACS+ servers MUST allow the administrator to configure the server to only accept challenge/response options for authentication (TAC_PLUS_AUTHEN_TYPE_CHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAP or TAC_PLUS_AUTHEN_TYPE_MSCHAPV2 for authen_type).
35c33
< TACACS+ server deployment administrators 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.
---
> TACACS+ server deployment administrators SHOULD enable the option mentioned in the previous paragraph. TACACS+ Server deployments SHOULD ONLY enable other options (such as TAC_PLUS_AUTHEN_TYPE_ASCII or TAC_PLUS_AUTHEN_TYPE_PAP) when unavoidable due to requirements of identity/password systems.
37c35
< TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft SHOULD not be used, 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.
---
> TAC_PLUS_AUTHEN_SENDAUTH and TAC_PLUS_AUTHEN_SENDPASS options mentioned in the original draft SHOULD not be used, due to their security implications. TACACS+ servers SHOULD deprecate them. If they are not deprecated, the servers MUST default to the options being disabled and MUST warn the administrator that these options are not secure.
41c39
< 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. 
---
> The authorization and accounting features are intended to provide extensibility and flexibility. There is a base dictionary defined in this document, but it 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. 
43c41
< 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.
---
> If a client receives a mandatory authorization attribute that its implementation does not define, then it SHOULD evaluate server response as if it had received TAC_PLUS_AUTHOR_STATUS_FAIL.
45c43
< 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).
---
> TACACS+ server deployment administrators SHOULD configure the server to reject authorization requests if authen_method value is not set to TAC_PLUS_AUTHEN_METH_TACACSPLUS.
49c47
< 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.
---
> 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 insecure, as it can reveal client shared secrets.
51c49
< TACACS+ server implementations SHOULD deprecate the redirection mechanism.
---
> TACACS+ servers SHOULD deprecate the redirection mechanism.
53c51
< 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.
---
> If the redirection mechanism is implemented then TACACS+ servers MUST disable it by default, and MUST warn deployment administrators that it must only be enabled within a secure deployment due to the risks of revealing shared secrets.
55c53
> TACACS+ clients SHOULD deprecate this feature by treating TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL.

---

From: Joe Clarke <[email-masked]>
Date: Sun, 15 Jul 2018 17:20:26 -0400

> 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 networ…

Agree with Alan that failure to deploy T+ securely _will_ impact overall
network security.

> 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…

I assume that administrators _will_ read this document.  Why wouldn't
they if it has guidance that will help them make their T+ deployments
more secure?

My comment is I would remove that sentence, as well as the "therefore"
in the sentence after it.

> TACACS+ server deployment administrators SHOULD change secret keys at regular intervals.

I'm not sure you need to keep saying, "server deployment
administrators".  Seems like "server administrators" is clear enough.

> 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.

Receives receiving?  That should be reworded.

> 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 prob…

You have "The the".  Remove the second "the".

Joe

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Mon, 16 Jul 2018 03:56:13 +0000

Hi Joe,

Thanks Joe, all useful comments. I believe that most of them were caught in the previous upload (in which we responded to Alan’s last mail), I will make sure that any missing are in the next.

On 16/07/2018, 0:20, "Joe Clarke" <jclarke=[email-masked]> wrote:

    

    

    

    
    Joe