Hi, apologies ... I've still some trouble to understand what kind of advantage the "allow the TACACS+ client to request the public keys from the TACACS+ server" option could give. On the implementation side, I have absolutely no trouble about the "T+ sends public-key to router" approach, that's easy enough.
However, I can't see the reasoning behind that. Why should the T+ server be excluded from determining whether a SSH key is legit or not? And why should the T+ server send a list of valid public keys to the router, at all? I propose a minimal change to the T+ protocol: Have a new authentication method, have the T+ server check the fingerprint hash (or even multiple hashes, both MD5 and SHA256) and you're done. Please share your insights about those issues. Cheers, Marc On 01.11.2022 15:58, Douglas Gash (dcmgash) wrote:
Dear OPSAWG Following is an outline of the Client/Server interaction promised earlier, to support SSH authentication with TACACS+… The key decision for the solution is: where should the SSH authentication proceed. The authors believe that it makes sense to continue to exploit the scale of crypto processing at the TACACS+ client level, rather than shifting this up to the TACACS+ server. Note that this model contrasts with the approach to proxy the SSH authentication up to the server, which the authors believe would not scale so well, but also encounters the fact that the authentication does not have extensible arguments that would be needed to fully communicate the required context to determine which keys should be selected. Therefore, the solution that will be presented has the following model: - The SSH client and the TACACS+ client (acting here as the SSH server) continue with the SSH processing roles they have now. - The TACACS+ authentication is extended to allow the TACACS+ client to request the public keys from the TACACS+ server, to ease ssh-key management - The TACACS+ authentication is extended to communicate the results of the TACACS+ client authentication processing to the TACACS+ Server, for the TACACS+ Server to log centrally and grant the final result for the TACACS+ client to enact. All other aspects will continue to use the TACACS+ protocol for processing of SSH requests as they do now. This approach will utilise the data field paradigm discussed earlier in the thread. We will follow with a document that describes the complete solution in detail. *From: *Douglas Gash (dcmgash) <[email protected]> *Date: *Thursday, 8 September 2022 at 16:47 *To: *Alan DeKok <[email protected]> *Cc: *[email protected] <[email protected]>, Andrej Ota <[email protected]>, Thorsten Dahm <[email protected]>, John Heasly <[email protected]> *Subject: *Re: [OPSAWG] TACACS+ SSH Enhancements Document Thanks Alan, We will follow up shorty with the client/server interaction which should help make more sense of “Our definition of the SSH authentication flow would then require us to cover the needed av-pairs, and the behaviour/error conditions etc, required for the SSH authentication flow.” Regards. *From: *Alan DeKok <[email protected]> *Date: *Thursday, 8 September 2022 at 14:56 *To: *Douglas Gash (dcmgash) <[email protected]> *Cc: *[email protected] <[email protected]>, Andrej Ota <[email protected]>, Thorsten Dahm <[email protected]>, John Heasly <[email protected]> *Subject: *Re: [OPSAWG] TACACS+ SSH Enhancements Document On Sep 8, 2022, at 6:47 AM, Douglas Gash (dcmgash) <[email protected]> wrote: > The alternative approach is to utilise the authentication packet data field. This field is used for all exchange of authentication materials in the current T+ protocol for applications such as CHAP based authentication flows. > > The exchange of artefacts required for the SSH authentication can similarly be embedded within the data field: the elements of the exchange would be wrapped in an existing av-pair format. That seems like a reasonable compromise. > Our definition of the SSH authentication flow would then require us to cover the needed av-pairs, and the behaviour/error conditions etc, required for the SSH authentication flow. The formatting of the artefacts in the data field would be left to the existing encoding format that is selected. I'm not clear what that means, but OK. The TACACS data fields are binary safe. So TACACS should be little more than an encapsulation layer for the SSH data. Ideally, the TACACS documents should specify how that data is encapsulated (named av-pairs, exchanges, etc). But the SSH data itself should be defined by a reference to an existing SSH document. > The potential advantage, from implementation perspective, is that the T+ stack can remain largely as-is. The changes are limited to a couple of new enum values for already existing enum ranges that and a bump is needed for the version. > Currently devices and servers will have business logic for each authentication type that they support, which use the data field (CHAP, MS-CHAP etc). The SSH may become plugged into this same level in the stack, which we can consider, is the appropriate place for it. > > We believe this option will enable an effective encapsulated upgrade approach for implementors, and welcome feedback. I think it's a good approach. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
