Of accounting data and security

[Michael Lecuyer]

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: