Hi Doug, all, Looks like there is agreement on scope. Thanks Doug for facilitating this.
Looking forward reading a first version of the draft ;-) Cheers, Med De : Douglas Gash (dcmgash) <[email protected]> Envoyé : lundi 16 mars 2026 17:57 À : EBALARD Arnaud <[email protected]>; Nils Warnke <[email protected]> Cc : Warnke, Nils <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]>; Joe Clarke (jclarke) <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: TACACS+ extension for SSH keys Transfer Thanks Arnaud. Thanks to Arnaud and John (Heasley) for working through and completing this analysis. From: EBALARD Arnaud <[email protected]<mailto:[email protected]>> Date: Monday, 16 March 2026 at 09:51 To: Nils Warnke <[email protected]<mailto:[email protected]>>, Douglas Gash (dcmgash) <[email protected]<mailto:[email protected]>> Cc: Warnke, Nils <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: TACACS+ extension for SSH keys Transfer Hi, As explained by Doug, the short summary is that PKI already come with various methods/usages to deploy certs on the targets. For instance, on all devices that will use T+TLS, X.509 certificates will already have been deployed for the protocol to work. Then, trying to use T+ to deploy certs for users authentication (e.g. on HTTPS admin interface of a device) did seem redundant, possibly complex and somewhat artificial. For certs-based deployments (e.g. X.509 client auth on https admin interfaces, OpenSSH certs for ssh), it is expected for device vendors to perform the authentication locally based on (previously) provisioned users CA info (i.e. T+ server will not be the place to centralize that), extract some relevant ID from provided cert's SAN or subject (possibly user configurable) and plug a common T+ authorization based on that ID. Simply put, unlike SSH pub key case for which authorization and authentication will be centralized at T+ server (and covered in the document), certs-based deployments (X.509 and OpenSSH) are only expected to benefit from T+ authorization. As written in Douglas' NOTE below, having some guidance somewhere regarding ID extraction from certs and associated T+ authorization would help promote the use of T+ for authorization with certs based authentication. In that context, this would be nice to have vendors with devices that can mostly be configured/administered with a https interfaces to join the discussion (e.g. Firewall vendors, etc.). Cheers, Arnaud De : Nils Warnke <[email protected]<mailto:[email protected]>> Envoyé : lundi 16 mars 2026 03:10 À : Douglas Gash (dcmgash) <[email protected]<mailto:[email protected]>> Cc : Warnke, Nils <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>; EBALARD Arnaud <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Objet : Re: TACACS+ extension for SSH keys Transfer Dear Doug, Dear WG, Many thanks for your recap, that helps to follow the thought process. In any case, I see this as really useful and would like to express our support for writing a draft on this extension. Best regards, Nils. Am 13.03.2026 um 23:57 schrieb Douglas Gash (dcmgash) <[email protected]<mailto:[email protected]>>: Dear Nils, Med, OPSAWG Recap: Before TLS was split from the security doc, it described a mechanism to transfer SSH certs needed for Device Administration authentication, Towards the tail end of the TLS doc timeframe this discussion was broadened to consider Certs for authentication, for example in the HTTLP administration context. However, we elected to revert to the original scope, here's a summary of the thoughts that lead us to excluding cert transfer: The discussion covered TACACS+ sending 3 (technically 2) types of certificates to TACACS+ clients. These would be the root of trust (certificate chain) of the ssh (etc) client's certificate. 1) openssh CA certificates ("bundles") 2) rfc6187 ssh CA certificates (bundles) 3) x509 CA certificates (bundles) That would also require providing KRLs and CRLs. Should TACACS+ be providing these? Should it send any chain requested? Should it be controlled by a policy? A user certificate might be denied by intentionally not including its CA/issuer. Other methods exist, at least 3, to distribute certificates; cli, netconf, gnsi. Also, one more for x509, which is do not distribute them at all, instead follow rfc5280 to resolve them from known roots. Those seem like the appropriate methods for distributing certificates... but the point regarding removal was included in the scope, acknowledging the likely need for further discussion, which would be welcome! NOTE: Even if the cert transfer is excluded and the other methods are still utilised, it may still be useful to define appropriate authorisation recommendations which relate to the preceding certificate based authentication, this will certainly be considered as part of the scope. Many thanks, The authors. From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Monday, 9 March 2026 at 11:15 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, Douglas Gash (dcmgash) <[email protected]<mailto:[email protected]>>, Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: TACACS+ extension for SSH keys Transfer Hi Med, Dear WG, Many thanks for this. Yes, we are very interested in solving topic this and I am happy to support the draft as operator. Regarding the limitations (Dropping scope for Certs for HTTPS authentication), I would be interested to understand the background. Maybe we could meet in Shenzhen to discuss? Best regards, Nils. Deutsche Telekom Technik GmbH Core Networks & First-Line Maintenance (T-CNF) Lead Architect of DT IP Core Solution Architecture Board Wolbecker Strasse 268, 48155 Münster Mob.: +49 151 720 122 46 E-Mail: [email protected]<mailto:[email protected]> www.telekom.de<http://www.telekom.de/> <image001.png> <image002.png> Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik<http://www.telekom.de/pflichtangaben-dttechnik> From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Monday, March 9, 2026 9:26 AM To: Douglas Gash (dcmgash) <[email protected]<mailto:[email protected]>>; Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>; EBALARD Arnaud <[email protected]<mailto:[email protected]>>; Warnke, Nils <[email protected]<mailto:[email protected]>> Cc: John Heasley <[email protected]<mailto:[email protected]>>; Thorsten Dahm <[email protected]<mailto:[email protected]>>; Andrej Ota <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: TACACS+ extension for SSH keys Transfer Hi Doug, all, Thanks for the follow-up and sharing this proposal. Adding Nils to have his feedback as well (as I know they are also interested to solve this). Cheers, Med De : Douglas Gash (dcmgash) <[email protected]<mailto:[email protected]>> Envoyé : vendredi 6 mars 2026 10:59 À : Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>>; EBALARD Arnaud <[email protected]<mailto:[email protected]>>; BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc : John Heasley <[email protected]<mailto:[email protected]>>; Thorsten Dahm <[email protected]<mailto:[email protected]>>; Andrej Ota <[email protected]<mailto:[email protected]>> Objet : TACACS+ extension for SSH keys Transfer ... with slightly more appropriate subject. Dear OPSAWG, Med, Joe, Arnaud. We plan to specify how SSH keys may be transferred over TACACS+ protocol, with idea that this specification document may be of interest to OPSAWG team to enhance interoperability. The approach was originally included in a general TACACS+ security document that also included TLS transport, however it was determined that the two subjects would best be handled by separate documents. The TLS part is completed, so we return to the SSH key transfer part. This note is intended to set the scope of the document. Based upon the feedback of the scope, we will follow up with the first revision for the document itself. 1 Purpose: (TLS) TACACS+ protocol extensions for transfer of public SSH Keys from the AAA server to the AAA client 2 What will be specified: * How the fields in the Authorization packets are used: * by the TACACS+ AAA Client to request, the Keys, * by the TACACS+ AAA Server to encode the Keys, * how the flow will be coordinated and completed. * Description of TACACS+ Role in the complete AAA SSH session flow (Authentication/Authorization/Accounting), and which phases are optional 3 Clarifications/Limitations * There is no intent to extend the actual SSH authentication out of the device over TACACS+ to the AAA server. The authentication flow is purely for the retrieval of the Keys. Consequently, other than abstaining from sharing the publicly available materials, the authorization phase is the only step where the TACACS+ Server may actually enact Policy Decision in the overall flow (as now). * There has been a previous call to including the distribution of other material (Certs for HTTPS authentication), this option has been dropped after further discussion. ____________________________________________________________________________________________________________ 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. 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. ____________________________________________________________________________________________________________ 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] To unsubscribe send an email to [email protected]
