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
