Hi all, Great to see that you converged quickly on this.
I suspect that the "second document" mentioned by Doug in this thread is https://datatracker.ietf.org/doc/html/draft-dahm-opsawg-tacacs-security. Cheers, Med De : Douglas Gash (dcmgash) <dcmgash=40cisco....@dmarc.ietf.org> Envoyé : lundi 1 juillet 2024 14:19 À : EBALARD Arnaud <arnaud.ebal...@ssi.gouv.fr>; opsawg@ietf.org Cc : John Heasly <h...@shrubbery.net>; Andrej Ota <and...@ota.si> Objet : [OPSAWG]Re: OPSAWG Digest, Vol 205, Issue 21 That is certainly reasonable, we will add. From: EBALARD Arnaud <arnaud.ebal...@ssi.gouv.fr<mailto:arnaud.ebal...@ssi.gouv.fr>> Date: Monday, 1 July 2024 at 12:21 To: Douglas Gash (dcmgash) <dcmg...@cisco.com<mailto:dcmg...@cisco.com>>, opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>> Cc: Thorsten Dahm <thorsten.d...@gmail.com<mailto:thorsten.d...@gmail.com>>, John Heasly <h...@shrubbery.net<mailto:h...@shrubbery.net>>, Andrej Ota <and...@ota.si<mailto:and...@ota.si>> Subject: RE: OPSAWG Digest, Vol 205, Issue 21 Hi Douglas, Thanks for that feedback. As you pointed, current state of the art is to provision users and their keys on the devices (up to the limits those devices have in term of number of keys and the burden of deploying and maintaining that on a large set of equipment) and not to use TACACS+ at all for the first A of AAA. AFAICT, this works for small networks with few administrators but does not scale at all (scaling being the purpose of TACACS+). In practice, people may end up deploying passwords because the spec (RFC 8907 and tacacs-tls) do not have guidance on the possible impacts of doing just that. I think that building on your comment and include what you wrote in the security considerations would be nice. What about explicitly stating in that section that current state of the art is to provision SSH pub keys on the devices and limit TACACSS work to authorization and accounting, and then add a disclaimer on the impacts of following the password way? This would be fair and could evolve once other drafts become RFC and allow TACACSS to take part in AAA w/ keys. Cheers, Arnaud De : Douglas Gash (dcmgash) <dcmg...@cisco.com<mailto:dcmg...@cisco.com>> Envoyé : lundi 1 juillet 2024 10:56 À : opsawg@ietf.org<mailto:opsawg@ietf.org>; EBALARD Arnaud <arnaud.ebal...@ssi.gouv.fr<mailto:arnaud.ebal...@ssi.gouv.fr>> Cc : Thorsten Dahm <thorsten.d...@gmail.com<mailto:thorsten.d...@gmail.com>>; John Heasly <h...@shrubbery.net<mailto:h...@shrubbery.net>>; Andrej Ota <and...@ota.si<mailto:and...@ota.si>> Objet : Re: OPSAWG Digest, Vol 205, Issue 21 Hi Arnaud, The need for enhancing the flow for SSH key authentication is clear, and the initial version of the document covered this to some degree. However, after discussion in the group the doc was split to cover TLS (as a priority), and a second document that is in preparation for SSH keys. To give a head's up on the current direction: The current state of art is that the SSH keys are normally provisioned on the devices (the AAA clients), and TACACS+ does not actually get involved with this authentication process, it sticks to the authorisation and the accounting. The direction that was being taken in the doc -before the SSH stuff was split out- and will be taken in the initial versions of the forthcoming separate doc for SSH, allows the AAA server to select and provision the SSH keys to the enforcement device (AAA client) during a new TACACS+ authentication flow. The enforcement devices would then continue to implement the SSH end-station endpoint authentication as now. In other words: the SSH authentication itself was not extended from the AAA client to the AAA server, just the SSH key provisioning. Date: Mon, 1 Jul 2024 08:14:27 +0000 From: EBALARD Arnaud <arnaud.ebal...@ssi.gouv.fr<mailto:arnaud.ebal...@ssi.gouv.fr>> Subject: [OPSAWG]Security Considerations regarding draft-ietf-opsawg-tacacs-tls13 To: "opsawg@ietf.org<mailto:opsawg@ietf.org>" <opsawg@ietf.org<mailto:opsawg@ietf.org>> Message-ID: <024067fa1d4c4269a6b472b45b0cc...@ssi.gouv.fr<mailto:024067fa1d4c4269a6b472b45b0cc...@ssi.gouv.fr>> Content-Type: multipart/alternative; boundary="_000_024067fa1d4c4269a6b472b45b0cc3bassigouvfr_" 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<mailto: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<mailto:contact.r...@sgdsn.gouv.fr>. If you have received this message in error, we thank you for informing the sender and destroying the message. -------------- next part -------------- A message part incompatible with plain text digests has been removed ... Name: not available Type: text/html Size: 6322 bytes Desc: not available ------------------------------ Subject: Digest Footer _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org<mailto:opsawg@ietf.org> To unsubscribe send an email to opsawg-le...@ietf.org<mailto:opsawg-le...@ietf.org> ------------------------------ End of OPSAWG Digest, Vol 205, Issue 21 *************************************** 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<mailto: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<mailto:contact.r...@sgdsn.gouv.fr>. If you have received this message in error, we thank you for informing the sender and destroying the message. ____________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
