Hello Med, yes, TLS keylog is a very powerful and dangerous tool and needs to be used with care. Where I thought it would be primarily be used is a test or staging environment where configurations are built, updated and tested before brought to production. If a tool, such as Wireshark, is used to help with this now, I'd say it would be useful to hint TACACS+ users and client and servers developers about the options they have when building configurations that use TLS.
What I'm thinking is that what can be done to help switching to TLS when it becomes available. At the moment everything is directly visible on the wire. This has made troubleshooting very easy: just watch what's going to if server or client debug logging does now help. With TLS 1.3 only the beginning of the handshake can be snooped directly before encryption is switched on. This is a very, very good thing and if users know how to do debugging with TLS, my hope is that it will make TLS adaptation faster. I understand why recommending TLS keylog in production can not be done. Could it be mentioned as a tool when developing and testing TLS enabled configurations? Thanks, Heikki On Tue, 26 Nov 2024 at 08:28, <mohamed.boucad...@orange.com> wrote: > Hi Heikki, > > > > I have one comment about the suggestion to indicate that > draft-ietf-tls-keylogfile is a better option. > > > > That spec says actually the following: > > > > This format is intended for use in > > systems where TLS only protects test data. While the access that > > this information provides to TLS connections can be useful for > > diagnosing problems while developing systems, this mechanism MUST NOT > > be used in a production system. > > > > I’m not quite sure we can recommend this mechanism here. > > > > Cheers, > > Med > > > > *De :* Heikki Vatiainen <h...@radiatorsoftware.com> > *Envoyé :* lundi 25 novembre 2024 19:18 > *À :* opsawg <opsawg@ietf.org> > *Objet :* [OPSAWG]draft-ietf-opsawg-tacacs-tls13: Debugging TACACS+ over > TLS > > > > > > Would it be possible to add some text about troubleshooting TACACS+ when > TLS is enabled? More exactly, add a reminder that TLS keylog > https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ is a better > option than: > > > > - trying to enable NULL encryption, authentication and integrity only, > ciphers for TLSv1.3 (see RFC 9150, supported by WolfSSL and OpenSSL 3.4); or > > - switching to non-TLS TACACS+ connections just because of troubleshooting > > > > Any of the above alternatives would likely require configuration changes > on the TACACS+ server and client side which may affect more connections > than necessary. After the troubleshooting is done, any changes to TLS > settings would also need to be reverted. This may be easy to forget leaving > the system in insecure state. > > > > The reason why debugging is done may also relate to the TLS handshake > itself in which case any changes to TLS settings may make the debugging > effort useless. I.e., the attempt to observe the system changes the system > behaviour. > > > > To provide some background, I work on AAA software named Radiator that has > supported TACACS+ for 20+ years. From what we see, Wireshark, as an > example, is often used to debug TACACS+. It's well-known, supports TACACS+ > well and very importantly, provides a neutral third party view of what's > going on between the client and server. Because Wireshark also supports TLS > keylog, it will likely continue to be a very important tool when TACACS+ > runs over TLS. > > > > Thanks to authors working on this! Please excuse me for being a bit late > for the party. > > > > -- > > Heikki Vatiainen > h...@radiatorsoftware.com > > ____________________________________________________________________________________________________________ > 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. > > -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
