I think that your suggestions about refocussing the document to clarify that the use case of TACACS+ is for Device Administration makes good sense. I agree it will likely entail a significant re-work, but I don¹t think that the author collective will shy from that. Further, I think this input will ultimately make it a better and more appropriate document, and hopefully, even a standard.
I also agree with change of terminology of the legacy encryption to obfuscation. Outright removal might be tricky, but instead casting it strongly as a deprecated may help bridge the gap. We may need a little time, but I think we can use this to get a good outcome, thanks for your patient input! Thanks, Regards, Doug. On 11/02/2016 22:59, "Alan DeKok" <[email protected]> wrote: >On Feb 11, 2016, at 4:14 PM, Douglas Gash (dcmgash) <[email protected]> >wrote: >> In terms of the data on top of the protocol, such as specific commands >>and >> arguments, then I think this is a higher level on the stack. I would >> suggest that this would generally be regarded as application layer >> configuration in the TACACS+ servers. > > That is a good argument... but it means that the purpose of the >protocol is little more than transporting vendor-specific data. Which >makes the protocol less relevant for standardization. > >> Is this level of standardisation, I.e. How device application level >> commands are encoded, acceptable to you, rathe than requiring we >> standardise the application level commands themselves? > > It's a step. But my concerns still remain. > > My concerns would be best addressed by pretty much re-writing the >document, and changing it's focus. Remove all of the discussion of >TACACS+ as a AAA protocol. Remove the definitions of Authentication, >Authorization, and Accounting, they are well known and defined in many >other places. Make it clear that the focus of the protocol is command >authorization, and nothing else. That other functionality is deprecated, >and SHOULD NOT be used. > > If that mirrors the current use-case for the protocol, these changes >should be acceptable. if the changes are not acceptable, then it's clear >that the protocol is intended to compete directly with RADIUS. In which >case I wold object strenuously to the document as a standards track >protocol. > > The security considerations section of the document needs to be more >than a paragraph. The non-TLS version of the TLS protocol should be >deprecated. > > For" 3.6.1. Legacy Body Encryption", the text should be changed to use >the term "obfuscation". The method described is not what would be >described in the crypto community as "encryption". IMHO, the packet >encryption method should be removed entirely, and TLS transport mandated. > > Alan DeKok. > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
