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.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
