Re: [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)

["Douglas Gash (dcmgash)" <[e-mail]>]

Hi Alan,

Many thanks for your feedback, as ever, we appreciate your valuable time and insights. We have added your comments as issues for tracking and resolution in the next version.

Please see inline for some initial response:

From: Alan DeKok <[e-mail]>
Date: Friday, 29 December 2023 at 01:15
To: Douglas Gash (dcmgash) <[e-mail]>
Cc: [e-mail] <[e-mail]>, John Heasly <[e-mail]>, Andrej Ota <[e-mail]>
Subject: Re: [OPSAWG] Submission of new version of TACACS+ TLS Spec (V4)
On Dec 22, 2023, at 11:53 AM, Douglas Gash (dcmgash) <dcmgash=[e-mail]> wrote:
> Some brief notes regarding the broader topics raised in v3, all items of course, are open for re-aligning as the group sees fit.
>
>        • Regarding the allocation of a specific port, a key motivation concerns the pervasive use of default ports in current configurations. Ensuring the client implementations work correctly with default ports now TLS is introduced, to minimise burden for operators whilst avoiding wrinkles with downgrade attacks does require said new default port to be allocated, and we will explicitly mention this in a new section in the new doc. We hope this should help account for our request for an allocated port.

  I think it's reasonable to allow use of the old port.  I would add a section explaining why this choice was made.  Perhaps also adding some text on how packet inspection systems / firewalls can distinguish the two protocols over the same port.

  For example, it may be useful for firewalls to allow TACACS+ traffic, but only if it's encrypted.

  The non-TLS TACAC+ connections have the first octet as 0xc0 or 0xc1, and the second octet is 0x01, 0x02, or 0x03.  Whereas TLS begins with a TLS handshake 0x16, followed by the TLS major version 0x03.

   I think it would be sufficient to just check the first octet.  If it's 0xc0 ... 0xcf, it's unlikely to be TLS and could be blocked.  Those values are unassigned in the TLS ContentType registry, and are likely to remain unassigned for the foreseeable future.

 I suspect that by the time those values are assigned for TLS ContentType, all uses of non-TLS TACACS+ would be long deprecated.
One of the main factors we have in mind regarding config the Secured T+ deployment, including port recommendations, is to try to do whatever we can to prevent unintended accidental mixing of secured and unsecured T+ traffic during migration of fleets of client devices, likely from different vendors with potentially different handling of default ports. In that context, we though a separate well defined port would offer advantages over re-using the original. A deployment can always override the defaults to get around a local challenge, but it wouldn’t be recommended.




>        • RFC9325 does look a timely reference, and we have tried to delegate what we can from the new TACACS+ doc to it.
>        • Tracking the discussion on the deprecation of obfuscation option inside TLS, our current reading is that:
>                • All TLS traffic must NOT use obfuscation.

  I would phrase that as "TACACS+ application data sent inside of a TLS tunnel MUST NOT use obfuscation".

>                • Setting the non-obfuscation option (TACACS has a flag for unencrypted)  is mandatory for all TLS TACACS+ traffic.

  Yes.

>                • The aim is to avoid any ambiguity and to remove MD5 operations from this level of the protocol.

  It would be good to give some explanation as to why MD5 is being removed.
Issue Tracking #14
In the document we say merely: “The MD5 Obfuscation specified in the original protocol definition is not fit for purpose,”
We’ll provide some reference as to why.



>        • We hope we have addressed the raised issues nits and ambiguities.

  It's looking good.

  Some additional nits on the new version:

* Section 2

  I would suggest some modifications to the terms.  Perhaps:

     Historic TACACS+: as defined in RFC 8907

  The intention here is to say also that it's not just "TACACS+ without TLS", but it's *historic* and should not be used.

    TACACS+TLS: TLS transport with TACACS+ as the application data
Issue Tracking #15 "Terms Cleanup"

Agreed


* Section 3

  Perhaps "TACACS+ over TLS" instead of "TLS for TACACS+" ?
Added to Issue Tracking #15 "Terms Cleanup"




  I don't think it's necessary for the first paragraph to re-explain how TACAC+ connections work.

  Perhaps also explain that TACACS+TLS is little more than a TLS wrapper around un-obfuscated TLS.  i.e. could it be implemented simply with stunnel + a historic TLS client/server?
Issue Tracking #16
We will rationalise the summary on T+, there are some restrictions on using a pure old server. Will clarify.


* Section 3.1

  Perhaps explain why the same port is being (or could be) used.
Well, as discussed above, we may have a divergence here 😉 What we actually say in the doc is: “where a different well-known system TCP/IP port is
   assigned by IANA,” so we do specify a different port. So I think we’d rather explain why a different port should be used. LMK if we have a conflict that requires resolution here, after we close that, I’ll raise appropriate ticket.


  "Therefore, TLS Hello MUST be initiated ..."

  What's a "Hello" ?  Perhaps just say instead that the connection begins with TLS, and leave it at that.

 "This document favors the predictable use of TLS security for a deployment"

  I'm not sure what that means.  Maybe "prefers" or "mandates" the use of TLS?  I find the phrasing to be confusing.
Issue Tracking #17
Agreed.


* Section 3.2.2

  It may be useful to move the TLS-PSK discussion from 5.1.3 to here.

  Though the RADEXT WG recently went through a long process of defining TLS-PSK for RADIUS.  It wasn't trivial.  See https://datatracker.ietf.org/doc/draft-ietf-radext-tls-psk/

  If the document is going to say "TLS-PSK is possible" but nothing more, then I would suggest just forbidding it.  There are a lot of details to get right with TLS-PSK.
Issue Tracking  #18
Thanks for the reference, we will attempt digestion the doc you kindly referred to, and optimise the doc structure to incorporate the elements we can extract.


* Section 3.4

  ALPN needs to have ALPN strings defined.  There's a similar (and long) discussion in https://datatracker.ietf.org/doc/draft-ietf-radext-radiusv11/

  TACACS+TLS doesn't need that level of complexity.  The RADEXT document is trying to be compatible with historic RADIUS, which is hard.  So it's a good idea to require the use of ALPN now.

  Perhaps for TACACS+TLS, just say that the client and server MUST use a particular ALPN string.  Maybe "tacacs+/12.1", which could mean both 12.0 and 12.1 versions of TACACS+,
Agreed. The doc is written on the assumption that we will negotiate a String (just like with the new port).


 Over all, I'd like to see more content in the document.  Right now it outlines how TACACS+TLS should work, but gives very little guidance to implementors or operators.  I'd suggest reading the RADEXT TLS-PSK and ALPN documents linked above.  They go into exhaustive detail about how every little bit is supposed to work.  I've found that documenting the protocol in such detail greatly improves the quality of the implementations, and is more likely to result in interoperation between the implementations.

We’ll Absorb that doc. I would prefer to defer raising an issue for tracking of the doc until we can determine the specifics to fix, and will forward details of the specific issues when we get there.
Regarding the TLS specifications and crypto choices, we have attempted as far as possible to defer to actual TLS specs docs and TLS best practices docs, such as RFC 9325. We have tried to restrict details of T+ to RFC8907, unless changes are required.
However, we do believe it is essential to help implementors and operators as much as we can at this point and will certainly be keen to leverage your experience with the docs you mention.
Many thanks as ever, please LMK on any of the answers above and regarding our potential divergence of our intent to recommend a different port.
Best Regards,
The Authors.


  Alan DeKok.