Hi, A cursory look suggests our implementation (on Aviat Networks WTM4000 series products) does follow the technical details in this standard. This is based on a cursory reading of the standard and the relevant source code - I haven't done any testing to ensure this. I note that we have made no special effort in this implementation to ensure security, besides requiring the use of obfuscation.
Regarding the recommendations, this implementation: * Does not support TAC_PLUS_UNENCRYPTED_FLAG (follows recommendation in 9.5) * Does treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL (follows recommendation in 9.5) * Does not check for unknown mandatory authorization attributes (against recommendation in 9.5) * Does not take any steps to ensure the channel is secure (this is left up to the network administrator) * Only supports PAP (against recommendation in 9.7) Single connection mode is not supported. We use session-based authentication - immediately after authentication we send an authorization request. The reply must contain a custom attribute to identify the allowed groups of commands, or else the login is denied. I believe this is not in disagreement with the standard. I also spotted a typo in 4.4.3: PALL should apparently be PASS. Regards, Alex ________________________________________ From: OPSAWG <opsawg-boun...@ietf.org> on behalf of Joe Clarke <jclarke=40cisco....@dmarc.ietf.org> Sent: Tuesday, 14 August 2018 7:19 a.m. To: opsawg@ietf.org Subject: EXTERNAL: [OPSAWG] TACACS+ IMPLEMENTORS: Does your implementation match draft-ietf-opsawg-tacacs? As you know, draft-ietf-opsawg-tacacs is working to describe the TACACS+ protocol as it is known to be implemented today. This draft will become an informational document and help inform subsequent works. As this document progresses towards ratification, the opsawg chairs are soliciting people that have implemented TACACS+ clients and/or servers to read the draft and comment as to whether or not their implementation is known to be compliant _or_ if it is known _not_ to be compliant. If the latter, and your implementation is known not to be compliant, what does your implementation do differently? If the former, an explicit acknowledgement that your implementation is compliant (and the name/vendor of said implementation) will be helpful as this document moves to the IESG. If you know of T+ implementors that may not be on the opsawg@ list, please forward this to them, and ask them to comment on list. Thank you. Joe (on behalf of the opsawg co-chairs) _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
