Subject: [OPSAWG] New Version of T+ informational note has been uploaded

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Thu, 14 Jul 2016 18:30:43 +0000

Hello all.

A new version of the T+ informational note has been uploaded.

For information: 

Version 3 loaded last week has many revisions from the last round of
comments.
Version 4 loaded this week has some minor mods/clarifications on US-ASCII
vs UTF-8.

Would appreciate any further reviews.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-04

Many thanks!

Author team.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Jul 2016 11:24:53 -0400

On Jul 14, 2016, at 2:30 PM, Douglas Gash (dcmgash) <[email-masked]> wrote:
> Hello

  Many of my review comments have been addressed, which is good.  There still remains a number of issues.

  The Security Considerations section is in the middle of the document, where it's typically at the end.  That's a minor nit.  The larger one is that the Security Considerations section is pretty minimal.  It should describe operational issues with the protocol, and comments as to what the security implications are for network management traffic to be sent in the clear.

  The issue with the field names remains.  I *suspect* the "user len" field contains the length of the "user" field... but there is nothing in the document which says so.

  The text still seems philosophical to me, instead of prescriptive.  For example in Section 3.6:

   After a packet body is decrypted, the lengths of the component values
   in the packet should be summed and checked against the cleartext
   datalength value from the header.  Any packets which fail this check
   should be discarded and an error signalled.

  The values "should" be summed?  Is that an RFC 2119 statement?  Or just a suggestion?  What happens if an implementation chooses to ignore this suggestion?

  And bad packets "should" be discarded?  Why not MUST?  How does an error get signalled?  What kind of error packet gets sent back?

  Perhaps something like this would be better:

   After a packet body is decrypted, the lengths of the component values
   in the packet are summed.  If the sum is not identical to the cleartext
   datalength value from the header,
   the packet MUST be discarded, and an error signalled.  The
   underlying TCP connection SHOULD also be closed.

  Which (for me) clarifies the operation, makes the checks normative, and adds a suggestion to close the TCP connection.  After all, if they key is wrong and packets can't be decrypted, there's no reason to keep the TCP connection open.  You can't decrypt any data in the connection, so it will all be garbage.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 15 Jul 2016 11:38:36 -0400

>  The Security Considerations section is in the middle of the document, where it's typically at the end.  That's a minor nit.  The larger one is that the Security Considerations section is pretty mi…

  For example:

Security Considerations

This specification describes a protocol as originally designed in 199X, and as such does not use modern security practices.  A later document will update TACACS+ to meet modern security standards.

There are a number of issues with the protocol design and common use-cases.  The most significant are issues related to privacy and authentication.  The protocol includes an obfuscation mechanism referred to in the original draft as Body Encryption.  This obfuscation method has not had security analysis, and should be assumed to be broken.  Portions of the protocol are sent clear-text, while others are sent obfuscated.  An attacker may be able to modify the clear-text portions without detection.

When the obfuscation mechanism is not used, the protocol is entirely unauthenticated.  Anyone capable of spoofing or intercepting traffic for the source or destination of the TCP connection can masqeurade as the client or server without detection.  This attack would allow a malicious after unrestricted access to the management devices allegedly "protected" by this protocol.

When the obfuscation mechanism is not used, the protocol is also completely open.  All traffic is visible to an eavesdropper, which can leak information about the network.  An eavesdropper may also be able to intercept, and modify, packets without detection.

  etc.  The section should list the possible attacks, and how to defend against them.

  Alan DeKok

---

From: "Douglas Gash (dcmgash)" <[email-masked]>
Date: Fri, 15 Jul 2016 19:32:11 +0000

Thank you again Alan for more quality feedback!

Regards,

Doug

> On 15 Jul 2016, at 16:38, Alan DeKok <[email-masked]> wrote:
>