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

Reply via email to