Re: [OPSAWG] I-D Action: draft-dahm-opsawg-tacacs-security-00.txt

["Douglas Gash (dcmgash)" <[e-mail]>]

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) <[e-mail]>
Date: Thursday, 30 June 2022 at 16:07
To: Alan DeKok <[e-mail]>, heasley <[e-mail]>
Cc: [e-mail] <[e-mail]>, Douglas Gash (dcmgash) <[e-mail]>, Andrej Ota <[e-mail]>, Thorsten Dahm <[e-mail]>
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 <[e-mail]> on behalf of Alan DeKok <[e-mail]>
Date: Wednesday, June 29, 2022 at 17:34
To: heasley <[e-mail]>
Cc: [e-mail] <[e-mail]>, Douglas Gash (dcmgash) <[e-mail]>, Andrej Ota <[e-mail]>, Thorsten Dahm <[e-mail]>
Subject: Re: [OPSAWG] I-D Action: draft-dahm-opsawg-tacacs-security-00.txt
On Jun 29, 2022, at 2:26 PM, heasley <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/opsawg