:) Wasn't suggesting I'd use TACACS+. I am in the process of replacing my customers existing TACACS+ architecture however they keep coming back to the ability of TACACS+ over Radius to secure, or rather, not send accounting data across the network in the clear. (I assume this is the case) I think I'm going to have to address this over and over again. N On Mon, Aug 9, 2010 at 12:52 PM, Michael Lecuyer <mjl@iterpacis.org> wrote:
We would be stuck with static weak security built in to RADIUS just like TACACS uses.
There are options for securely tunneling RADIUS packets that weren't available in the early years. Secure tunneling doesn't require changes to the RADIUS protocol. The EAP-TLS extension alone has made most of RADIUS secure.
For TACACS changing the encoding means re-writing every client and server. Tunneling TCP through SSL takes way too many packets to efficiently perform a large number of each separate authentication, authorization and accounting transaction.
Built in transport security is a bad idea. For TACACS it is the only way since PAP/ASCII authentication and password changes really are sent in plain text.
Please, no more talk of TACACS. Its not a good example of anything.
Natr Brazell wrote:
Curious why we're fortunate? Could you elaborate some? On Sun, Aug 8, 2010 at 10:01 PM, Michael Lecuyer <mjl@iterpacis.org<mailto: mjl@iterpacis.org>> wrote:
TACACS+ uses an MD5 pad based on the session ID, shared secret, TACACS+ version, and packet sequence number. This is XOR'd over the packet. The pad is in multiples of the MD5 hash length.
The header is sent plain text and includes the sequence number, the session ID and version number.
Encoding and decoding are symmetrical. It is not considered strong encoding.
We're all fortunate RADIUS doesn't use this to encode packets.
Natr Brazell wrote:
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html