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) <dcmg...@cisco.com> Date: Thursday, 8 September 2022 at 16:47 To: Alan DeKok <al...@deployingradius.com> Cc: opsawg@ietf.org <opsawg@ietf.org>, Andrej Ota <a...@google.com>, Thorsten Dahm <thorstend...@google.com>, John Heasly <h...@shrubbery.net> 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 <al...@deployingradius.com> Date: Thursday, 8 September 2022 at 14:56 To: Douglas Gash (dcmgash) <dcmg...@cisco.com> Cc: opsawg@ietf.org <opsawg@ietf.org>, Andrej Ota <a...@google.com>, Thorsten Dahm <thorstend...@google.com>, John Heasly <h...@shrubbery.net> Subject: Re: [OPSAWG] TACACS+ SSH Enhancements Document On Sep 8, 2022, at 6:47 AM, Douglas Gash (dcmgash) <dcmg...@cisco.com> 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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
