Of accounting data and security
Natr Brazell
natrbrazell at gmail.com
Mon Aug 9 22:19:48 CEST 2010
:)
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 at 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 at iterpacis.org<mailto:
>> mjl at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20100809/edcabd05/attachment.html>
More information about the Freeradius-Users
mailing list