Thanks to feedback from Alan D, Marc H, Toerless E, Michael R, (apologies if I missed anyone).
The reception of the proposal was… mixed. We would like to present an alternative approach, as John mentioned. 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. 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. 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. Regards, The Authors. From: Alan DeKok <[email protected]> Date: Tuesday, 30 August 2022 at 21:17 To: John Heasly <[email protected]> Cc: Michael Richardson <[email protected]>, Douglas Gash (dcmgash) <[email protected]>, [email protected] <[email protected]>, Andrej Ota <[email protected]>, Thorsten Dahm <[email protected]> Subject: Re: [OPSAWG] TACACS+ SSH Enhancements Document On Aug 30, 2022, at 3:48 PM, John Heasly <[email protected]> wrote: > It is not a new format, it is the format currently used in the > authorization and accounting parts of tacacs, except with no fixed > fields. AVPs are its own version of TLVs that have existed since the > beginning of tacacs, so that code has existed as long. It's changing the existing format for authentication packets. So it's a change.. but to something which likely already has code support in TACACS+ implementations. > We are not eager to remove the fixed fields that exist or make any > drastic changes. Douglas assembled an example to ensure that we > understood by example what Alan's comment was about - existence of fixed > fields at all or that we'd originally proposed adding a fixed field (to > make Authen consistent with Author/Acct) or something else entirely. My concern was with adding a new header which was different from existing ones, and which used yet more fixed fields, >> Please consider RFC8949: CBOR. > > If you want the authentication part changed to CBOR or whatever the > flavour of the month is, then you also want authorization and accounting > to change? IE: you want a complete restructure of all of the packet > formats used in tacacs. > > I do not see how that is less likely to result in bugs in areas unrelated > to (de)serialization and will impede implementation. There is no good solution here. There are strong reasons to just "patch" existing implementations with minimal changes. That enables quick implementation and deployment. There are also strong reasons to use a modern format which has extensive implementations: https://cbor.io/impls.html If we stick with the current TACACS+ format, then we still need to serialize / deserialize the data. There are likely issues related to encoding binary data in textual format. And perhaps multiple representation formats of the same data. If there is an argument against CBOR, it would be "CBOR doesn't match what we need to do in TACACS+". As reference, the CBOR data types are: • an integer in the range -264..264-1 inclusive • a simple value, identified by a number between 0 and 255, but distinct from that number itself • a floating-point value, distinct from an integer, out of the set representable by IEEE 754 binary64 (including non-finites) [IEEE754] • a sequence of zero or more bytes ("byte string") • a sequence of zero or more Unicode code points ("text string") • a sequence of zero or more data items ("array") • a mapping (mathematical function) from zero or more data items ("keys") each to a data item ("values"), ("map") • a tagged data item ("tag"), comprising a tag number (an integer in the range 0..264-1) and the tag content (a data item) Does this meet the expected use-case? As an implementor, I can sympathize with the approach of "minimal changes". But 15 years of minimal changes can result in a horrible mess. There's also a good argument for saying "Look, we're going to do a bunch of stuff with TACACS+, so we might as well fix it now". Using a standard format such as CBOR means that the initial cost to implementations is large. But any further extensions are likely to be trivial. Alan DeKok.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
