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