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

["Joe Clarke (jclarke)" <[e-mail]>]

Fair point.  I was agreeing to the dedicated port for tacacss.  That said, I do believe tacacss meets the secure requirement set forth in 7605 with respect to creating a new, secure service that replicates and insecure service in a non-backwards compatible way.

That part of Section 7.1 should be cited as a justification for the assignment.

Joe

From: [e-mail] <[e-mail]>
Date: Wednesday, July 5, 2023 at 11:04
To: Joe Clarke (jclarke) <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt
Hi Joe, all,

On the port number point, I’m afraid that the arguments in Section 8 are more for justifying why distinct port numbers might be useful, not why a well-known port number has to be assigned. I would suggest to strengthen that part before making the request (see more in rfc6335#section-7.2 and also rfc7605#section-7).
Cheers,
Med

De : OPSAWG <[e-mail]> De la part de Joe Clarke (jclarke)
Envoyé : mercredi 5 juillet 2023 16:42
À : [e-mail]
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

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 <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 29, 2023 at 10:55
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/opsawg

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.