Hi, I would like to apologize for the late timing in providing the following comments.
The Security Considerations section of RFC 8907 properly describes TACACS+ scrambling mechanism and associated impacts. This tacacs-tls draft addresses *this* specific issue by replacing the scrambling mechanism by state of the art cryptography using TLS 1.3. It is likely that TACACSS will end up being the new standard to build secure AAA architecture for administrating network equipment. To my knowledge, there is however a blind spot going down this sole path in that it will end up reducing the security of network architectures in which TACACSS will be deployed. I am not objecting to advancing this specification but it would be fair to properly record this blind spot in the document so that people can weigh the pros and cons before going all-in on TACACS+/S. Nowadays, if one tries to implement a secure administration architecture, they will almost certainly consider using asymmetric keys (possibly in cryptographic tokens) instead of passwords for authentication to remote systems using SSH or HTTPS. There are various reasons for this evolution: using a signature provides a strong authentication, it does not leak the secret outside of the administrator workstation (or token), populating a remote device is a matter of installing a public part (key for SSH, CA for X.509 certs) instead of manipulating a password or a salted hash, etc. On the contrary, when a user logs onto a system using a password, the (possibly compromised) remote system gets access to that password. The blind spot with TACACS+/S is that the protocol only supports passwords as its authentication mechanism and thus currently comes with a security price for the functionalities it provides. It gets even worse because this password will end up being valid for all the equipment under the TACACS+/S server control. Hence, a single compromised system in a TACACS+/S environment leads to the compromise of the whole domain. Until TACACS+/S evolves to deprecate password-based authentication mechanisms in favor of state of the art ones (such as SSH public keys, etc), the Security Considerations section of the draft should mention the limitations associated with using TACACSS as is. If the WG agrees with my assessment, I can propose some text to highlight the concern. Comments are welcome, Cheers, Arnaud Les donn?es ? caract?re personnel recueillies et trait?es dans le cadre de cet ?change, le sont ? seule fin d'ex?cution d'une relation professionnelle et s'op?rent dans cette seule finalit? et pour la dur?e n?cessaire ? cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos donn?es, veuillez contacter contact.r...@sgdsn.gouv.fr. Si vous avez re?u ce message par erreur, nous vous remercions d'en informer l'exp?diteur et de d?truire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.r...@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
