Hi Douglas, I think what you call "keying material" in the first two paragraphs of your email is the authorized_keys (definition of acceptable user public keys on the network equipment). Currently, the definitions of the authorized_keys is local, the draft describes how T+ provides it (i.e. make it remote, under the control of T+ server). This is the description I made.
Regarding 1), I considered 3 schemes: SSH w/ pub keys, SSH with certs, TLS with X.509 certs. Regarding 2), the two approaches are 1. public keys for SSH vs 2. certs for both SSH and TLS. Extending the authentication itself to the AAA (in the context of SSH w/ keys/certs or TLS with certs) is something we can add to the discussion but I do not see at the moment both the path and the benefit. Arnaud De : Douglas Gash (dcmgash) <[email protected]> Envoyé : jeudi 9 octobre 2025 11:31 À : EBALARD Arnaud <[email protected]>; [email protected]; [email protected] Objet : [OPSAWG]Re: draft-dahm-opsawg-tacacs-security: update plan? Thank you, Arnaud for the summary. The current situation on the ground (as I understand it) is that the devices (across vendors) may be configured locally through their own interfaces with the keying material for SSH. Once this material has been used to complete a SSH authentication, then the AAA client uses T+ session authorization to allow the AAA server to determine what access is granted with its own policy. The challenge that is identified is the need to locally configure the keying material. To this end, the T+ security draft proposes that the authentication protocol of T+ is extended to allow the AAA client to obtain the keying material for the user so that the AAA client can then proceed as before. This is not actually extending the SSH authentication to the AAA server, but it does allow the AAA server to determine which keying material is used. Your mail certainly though, covers more. I would be grateful if you could clarify a couple of points on the mail below: 1. "When a user connects to a device using one of those 3 schemes," I see 2 schemes were mentioned (SSH/HTTPS) or does the SSH refer to 2 (public keys and certs)? 2. "a decision should be taken by the WG on the interest of work on one or both approaches, in sequence or in parallel. This involves understanding investment capabilities from people of the WG and the interest from both vendors and end-users." Just to make sure I'm on the same page, does the mention of the two approaches refer to the 2 schemes (Public keys/Certs) or to the two methods (where method one is for T+ just to transfer the key material, and method 2 is to extend the authentication itself to the AAA server). Many thanks! From: EBALARD Arnaud <[email protected]<mailto:[email protected]>> Date: Thursday, 9 October 2025 at 09:20 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Douglas Gash (dcmgash) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: draft-dahm-opsawg-tacacs-security: update plan? Hi Mohamed, all, In the rest of this email, TACACS stands for TACAS+TLS. Regarding the shared problem statement, I think most has been described in details on the list [1], but here is a summary: """ TACACS currently supports only password authentication. Those admin passwords disseminate on all equipments where they can be picked by attackers to compromise the whole network. Extensions of the protocol are needed to support authentication mechanisms which do not disseminate credentials on target system (such as public key-based schemes) while still maintaining the centralized capabilities (AAA) of the protocol. """ AFAICT, in current deployments, TACACS is used on devices accessed mainly using SSH and HTTPS. Considering those two protocols as a basis for discussion, they both allow for the use of public-key based authentication schemes: - SSH has support for public keys and (Open)SSH certificates. - HTTPS has X.509 client certificates When a user connects to a device using one of those 3 schemes, validating the assumed user identity X (i.e. authenticating X) usually involves 1/ securly accessing a mapping between X (and additional attributes) and a public key (by validating cert signature against a CA, consulting a local or remote authorized_keys file). 2/ validating the user has the associated private key (done inside SSH and TLS) 3/ considering revocation information (CRL, OCSP, etc.) Authorizing the user can then be done based 4/ on X, on subject/principal or another attribute in certificate I think SSH and X.509 Certificates have both structural similarities and the same kind of cinematic in their use in TLS and SSH. Without modifying the protocols themselves, authentication (1/, 2/ and 3/) is and will be done by the protocol and the question of integration with TACACS is mainly the question of extracting information from the certificates to be sent to TACACS server for authorization step (4/). Standardization work on TACACS Authorization for cert-authenticated SSH or TLS would IMO be a matter of defining what can be extracted from both kinds of certs and most importantly how it can be conveyed (e.g. DER vs unicode vs ...). This work would help aligning vendors/products (having web or cli interfaces using user cert-based authentication) on a way to plug w/ TACACS servers for authorization. For the case of TLS (unlike SSH), the integration of the TACACS client with the application (e.g. HTTP handling code) may be more difficult to standardize, if this is even considered a topic for the WG. Regarding SSH user public key authentication, the approach of draft-dahm-opsawg-tacacs-security is simple and nicely integrates with the usual cinematic of SSH. It makes TACACS server a remote storage for (usually local) authorized_keys file for a given user. This de facto makes the TACACS server in control of the authentication. The revocation of compromised *user* keys (see (*)) is also straightforward, by removing a key entry in the TACACS server for the user. TACACS authorization capabilities are kept as is. >From the elements above, the questions/directions I see are: - the SSH-only authorized_keys approach is simple and already has a draft to work on - the handling of certificate based approach for SSH and TLS may require some thinking and analysis to provide some basic initial common interface for X.509 and SSH certificates while allowing later evolution. The advantage could be the ability to expand the scope of TACACS to web-based devices/products, and more generally TLS-protected protocols. - a decision should be taken by the WG on the interest of work on one or both approaches, in sequence or in parallel. This involves understanding investment capabilities from people of the WG and the interest from both vendors and end-users. - if considering the certificate approach as WG item, should TACACS client integration w/ the application be included in the perimeter Feel free to add topics to the list above. (*): the additional complexity of the certificate approach for SSH (TLS also) comes with a useful security benefit that must be advertised, compared to the authorized_keys approach. Both clients *and* servers certificates are signed by a trust anchor, which means they provide a simple and efficient way to prevent the TOFU issue of SSH. Comments are welcome. Cheers, a+ [1] https://mailarchive.ietf.org/arch/msg/opsawg/vdhi_wqIOLTOA7CN42WYk__d2-g/ -----Message d'origine----- De : [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Envoyé : mercredi 8 octobre 2025 17:14 À : EBALARD Arnaud <[email protected]<mailto:[email protected]>>; Douglas Gash (dcmgash) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Objet : [OPSAWG]Re: draft-dahm-opsawg-tacacs-security: update plan? Re-, Thanks all for the positive feedback received so far. Start with framing the problem and identifying the list of issues to address looks like a good idea. @Arnaud, if you can draft something to iterate on, this would be helpful. Thank you. Cheers, Med > -----Message d'origine----- > De : EBALARD Arnaud > <[email protected]<mailto:[email protected]>> Envoyé : > mercredi 8 > octobre 2025 10:46 À : BOUCADAIR Mohamed INNOV/NET > <[email protected]<mailto:[email protected]>>; Douglas > Gash (dcmgash) > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> Objet : RE: > draft-dahm-opsawg-tacacs-security: update plan? > > > Hi all, > > I'll happily take part in the discussion. > > I think it would be useful to have some kind of shared problem > statement (not necessarily a separate document) so that we all agree > both on the issue and the goals of that work. Then, some possible > solutions should be considered based either on IETF previous work > (e.g. draft-dahm-opsawg-tacacs-security) and/or other initiatives > (some vendors are currently pushing in their products the ability to > use SSH certificates for authentication coupled w/ tacacs+ for > authorization based on the identity in the certificate). I can try and > start a list of topics to be addressed if you think it would help > (authorization-only vs > authentication+authorization, revocation, ability to support HTTPS > w/ X.509 client authentication and not only SSH, etc.). > > Cheers, > > Arnaud > > -----Message d'origine----- > De : [email protected]<mailto:[email protected]> > <[email protected]<mailto:[email protected]>> > Envoyé : mercredi 8 octobre 2025 08:50 À : EBALARD Arnaud > <[email protected]<mailto:[email protected]>>; Douglas Gash > (dcmgash) > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> Objet : [OPSAWG]draft-dahm- > opsawg-tacacs-security: update plan? > > Hi all, > > Now that we are about close to get the TACACS+TLS RFC out of those > door, I'd like we start discussing (and hopefully converge on a > plan) about how to address a key pending operational issue that we > recorded in the T+TLS spec: > > This document concerns the use of TLS as transport for TACACS+, and > does not make any changes to the core TACACS+ protocol, other than > the direct implications of deprecating obfuscation. Operators MUST > be cognizant of the security implications of the TACACS+ protocol > itself. Further documents are planned, for example, to address the > security implications of password based authentication and enhance > the protocol to accommodate alternative schemes. > > See also the discussion in [1]. > > Some of these points can be addressed by refreshing draft-dahm- > opsawg-tacacs-security. > > Thoughts, suggestions, and volunteers to drive this work are welcome. > > Cheers, > Med > > [1] > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fmsg%2Fopsawg%2FneElBSTsv4s64434gN8MC > aqZLCk%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8ede2ce7 > 7ec747ae3fec08de064732ec%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C638955100056250734%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=iLdupeEGJZx48OsbD46LnPbcmO9J3BCDCpt669O > P4%2Fg%3D&reserved=0 ____________________________________________________________________________________________________________ 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 -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]>. 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: [email protected]<mailto:[email protected]>. If you have received this message in error, we thank you for informing the sender and destroying the message. 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 [email protected]. 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: [email protected]. If you have received this message in error, we thank you for informing the sender and destroying the message.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
