Hi, First would be good to make sure the intent is clear: Though the TLS 13 draft is simply to do the TLS encapsulation, the security draft is primarily to support the SSH key distribution during T+ authentication.
To do this we added the variable arguments to authentication phase so that authentication phase matches the pattern already established in the protocol for authorization and accounting phases. The feedback is pretty clearly though, not to do this. Let us take a look at the options. From: Joe Clarke (jclarke) <[email protected]> Date: Thursday, 30 June 2022 at 16:07 To: Alan DeKok <[email protected]>, heasley <[email protected]> Cc: [email protected] <[email protected]>, Douglas Gash (dcmgash) <[email protected]>, Andrej Ota <[email protected]>, Thorsten Dahm <[email protected]> Subject: Re: [OPSAWG] I-D Action: draft-dahm-opsawg-tacacs-security-00.txt Thanks for your continued attention to this work, Alan. Your insight is very much appreciated.</chair> As an contributor, I rather like the simpler TLS encap over T+ approach described in the tls13 draft. I’d personally not over-engineer something that isn’t immediately required. T+ has been around for a while and is heavily used. I don’t know that we need to spend time adding extensibility. Joe From: OPSAWG <[email protected]> on behalf of Alan DeKok <[email protected]> Date: Wednesday, June 29, 2022 at 17:34 To: heasley <[email protected]> Cc: [email protected] <[email protected]>, Douglas Gash (dcmgash) <[email protected]>, Andrej Ota <[email protected]>, Thorsten Dahm <[email protected]> Subject: Re: [OPSAWG] I-D Action: draft-dahm-opsawg-tacacs-security-00.txt On Jun 29, 2022, at 2:26 PM, heasley <[email protected]> wrote: > We have received no comments about this draft, which I presume means no > technical objections exist. So, I would like to ask the Chairs for an > adoption call. I would suggest that ~3 weeks is a little too short a time frame to claim that there are no objections. I'll point to the previous TACACS+ document, where there were multiple reviews which got addressed by the authors many months later. I'll also point to my earlier review of draft-dahm-tacacs-tls13-00.txt, where I had concerns with extending the 1990s style TACACS+ packet format. The same concerns apply here. If we're going to extend TACACS+ by adding major new features, I would suggest that it's a priority to design these features correctly, the first time. Experience shows that it is extremely difficult to extend fixed-field packet formats. It's almost always better to use an extensible format, as with DHCPv4, DHCPv4, DNS options, YANG, RADIUS, Diameter, etc. Using a format with fixed fields now makes it more difficult to extend TACACS+ in the future. There will just be one complex format added after another. The alternative is instead to define an extensible format, in which case new extensions become trivial. 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
