Subject: [OPSAWG] TACACS+ IMPLEMENTORS: Does your implementation match draft-ietf-opsawg-tacacs?

From: Joe Clarke <[email-masked]>
Date: Mon, 13 Aug 2018 15:19:33 -0400

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)

---

From: Alex Campbell <[email-masked]>
Date: Tue, 14 Aug 2018 01:04:42 +0000

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 <[email-masked]> on behalf of Joe Clarke <jclarke=[email-masked]>
Sent: Tuesday, 14 August 2018 7:19 a.m.
To: [email-masked]
Subject: EXTERNAL: [OPSAWG] TACACS+ IMPLEMENTORS: Does your implementation match draft-ietf-opsawg-tacacs?

Thank you.

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Aug 2018 13:11:51 -0400

> is known to be compliant _or_ if it is known _not_ to be compliant.

  We've implemented it in FreeRADIUS.  (Perhaps mis-named...)

* we support the TAC_PLUS_UNENCRYPTED_FLAG, tho that may change.
* Does treat TAC_PLUS_AUTHEN_STATUS_FOLLOW as TAC_PLUS_AUTHEN_STATUS_FAIL (follows recommendation in 9.5)
* Does not take any steps to ensure the channel is secure (this is left up to the network administrator)
* it supports PAP, with CHAP and MS-CHAP in the works