Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

Hi authors,

I still unsure whether the

   Obsolescence of TACACS+ Obfuscation

section could hinder implementations and migrations using TLS wrappers
(load balancers, e.g.). I'd still suggest to change the "MUST" clauses
regarding obufuscation to "SHALL". There's no gain to change the
protocol at this point, it's sufficient to wrap it in TLS. If a client
insists in using obfuscation-over-TLS, that should be fine, even if it's
of no use.

Regarding a dedicated TCP port: Is there really a need for that, or
would this rather be an convenience option? A specific port number
limits the attack surface to a single port, and I don't see any need for
that.

Nevertheless .. those are not show-stoppers, and I welcome anything that
move this forward, so just continue the RfC process if you feel fine
with the current draft.

@Joe Cleake: I 've implemented TLS support, experimentally, to ease
starting client implementation. This doesn't qualify as a reference
implementation as I plainy don't know about any 3rd party clients to
test with. Your preferred search engine should easily find that
implementation.

Thanks,

Marc

On 05.07.2023 16:42, Joe Clarke (jclarke) wrote:
>
> Thanks for the update on this document. I’ve reviewed this new version
> in its entirety.  To summarize:
>
>   * TACACS+ TLS will use a dedicated “tacacss” TCP port number
>   * Obfuscation is prohibited by TACACS+ TLS compliant clients/servers
>     (within the tunnel)
>
> These were two issues I believe were discussion points in the WG.  As
> a contributor, I am convinced that both make sense for the reasons put
> forth in the draft. Hopefully during the migration process,
> implementors won’t forget the obfuscation on non-TLS sessions.
>
> I like the migration section, but I am curious why, after migration,
> one would need any legacy servers at all (regardless of server
> lists).  I can see having my “DEVICE_ADMIN” T+ list having both TLS
> servers first followed by legacy servers while I sus out the stability
> of the new implementation.  But when I’m satisfied, I likely would
> remove the legacy servers altogether.  Moreover, at least with Cisco
> config, I assume I’d have each server defined with various TLS
> attributes and it wouldn’t matter what list they are in.
>
> I guess what I’m suggesting is dropping the second paragraph in
> Section 6.2 and saying something to the effect of, when migration from
> legacy, obfuscated T+ to T+ TLS, insecure and secure servers MAY be
> mixed in redundant service lists.  However, secure servers SHOULD be
> tried first before falling back to insecure servers.
>
> As a nit, Indication is misspelled in Section 3.3.
>
> As co-chair:
>
>   * WG, please review this draft!
>   * Authors, any thoughts to what port number to use for tacacss or
>     whatever IANA can assign?  I’d like to see a few more reviews
>     before pinging the ADs on early allocation.
>   * Are there any implementations of this thus far?  If so having an
>     Appendix for them would help.
>
> Joe
>
> *From: *OPSAWG <opsawg-bounces@ietf.org> on behalf of
> internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Date: *Thursday, June 29, 2023 at 10:55
> *To: *i-d-announce@ietf.org <i-d-announce@ietf.org>
> *Cc: *opsawg@ietf.org <opsawg@ietf.org>
> *Subject: *[OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Operations and
> Management Area Working Group (OPSAWG) WG of the IETF.
>
>    Title           : TACACS+ TLS 1.3
>    Authors         : Thorsten Dahm
>                      Douglas Gash
>                      Andrej Ota
>                      John Heasley
>    Filename        : draft-ietf-opsawg-tacacs-tls13-03.txt
>    Pages           : 12
>    Date            : 2023-06-29
>
> Abstract:
>    The TACACS+ Protocol [RFC8907] provides device administration for
>    routers, network access servers and other networked computing devices
>    via one or more centralized servers.  This document, a companion to
>    the TACACS+ protocol [RFC8907], adds Transport Layer Security
>    (currently defined by TLS 1.3 [RFC8446]) support and obsoletes former
>    inferior security mechanisms.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-03.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-03
>
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg