On Aug 31, 2022, at 10:41 PM, Alan DeKok wrote: > My related question is what *else* do people envision doing with > TACACS+? If it's 1-2 things and then done, a small change can be > acceptable. If there's a long list of new things to do, then it's time > to do TACACS+ 2.0.
My favorites are: - client SSH key verification - client SSH certificate verification. - Context-awareness for command authorization: Have the NAD tell the server whether the user session is in exec or config or whatever else mode, and specify detailed context if there's a hierarchy (examples: "interface Ethernet 1", "router eigrp xxx"-"address-family ipv4 ...") - Let the NAD share vendor/device type/version information. All of that could be enabled with (extended) arguments available for authentication. However, focused on "client SSH key verification": That one is trivially implementable using a dedicated TAC_PLUS_AUTHEN_TYPE and SSH fingerprints, without any packet format changes. Would anybody here support that? That question is specifically addressed to NAD manufacturers. In fact, all changes or extensions to the protocol are pretty worthless without manufacturer support. Cheers, Marc _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
