Re: Of accounting data and security

2010-08-10 Thread Johan Meiring

On 2010/08/09 11:14 PM, Alan DeKok wrote:

   The accounting data is sent in the clear on a LAN.  This shouldn't be
a problem.

   If you're sending accounting data across the Internet, use IPSec.
Don't even pretend to use anything else.  RADIUS (and TACACS+) security
is simply not as good as IPSec.



Hi,

I've also got a need to implement security in the near furture.

I've not started yet, but my problem is that the embedded devices that I use 
do not have enough flash to install the encryption needed for ipsec.


My thinking was to use radsecproxy-freeradius (my nas, coova, supports radsec).

Any comments on ipsec vs radsec?

Thanks,



--


Johan Meiring
Cape PC Services CC
Tel: (021) 883-8271
Fax: (021) 886-7782

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Of accounting data and security

2010-08-10 Thread Alan Buxey
Hi,

 My thinking was to use radsecproxy-freeradius (my nas, coova, supports 
 radsec).
 
 Any comments on ipsec vs radsec?

RADIUS with TLS over TCP  (what some define as 'RADSec') is good. cant wait 
until
all mainstream RADIUS servers support it natively.  until then, RADSecproxy 
will do
what you want

alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Of accounting data and security

2010-08-10 Thread Natr Brazell
Thanks Alan,

At the moment we have restricted the accounting data to a layer 2 VPLS
segment however I'll investigate the use of IPSEC as well to let those that
worry about these things sleep better at night.

n

On Tue, Aug 10, 2010 at 3:53 AM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote:

 Hi,

  My thinking was to use radsecproxy-freeradius (my nas, coova, supports
 radsec).
 
  Any comments on ipsec vs radsec?

 RADIUS with TLS over TCP  (what some define as 'RADSec') is good. cant wait
 until
 all mainstream RADIUS servers support it natively.  until then, RADSecproxy
 will do
 what you want

 alan
  -
 List info/subscribe/unsubscribe? See
 http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Of accounting data and security

2010-08-09 Thread Michael Lecuyer
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:

Thanks,
 
I'm looking into IPSEC at the moment.  I'm curious how TACACS+ does 
their encryption?
 
N


On Fri, Aug 6, 2010 at 4:09 PM, Alan DeKok al...@deployingradius.com 
mailto:al...@deployingradius.com wrote:


Natr Brazell wrote:
  Is there a way to secure the communication between the radius
server and
  the NAS especially wrt accounting data?

 IPSec.

 Most NASes implement IPv4, and not much else.  Security means don't
run RADIUS over a network where users have access.

 Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html





-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Of accounting data and security

2010-08-09 Thread Natr Brazell
Curious why we're fortunate?  Could you elaborate some?

On Sun, Aug 8, 2010 at 10:01 PM, Michael Lecuyer m...@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:

 Thanks,
  I'm looking into IPSEC at the moment.  I'm curious how TACACS+ does their
 encryption?
  N

 On Fri, Aug 6, 2010 at 4:09 PM, Alan DeKok al...@deployingradius.commailto:
 al...@deployingradius.com wrote:

Natr Brazell wrote:
  Is there a way to secure the communication between the radius
server and
  the NAS especially wrt accounting data?

 IPSec.

 Most NASes implement IPv4, and not much else.  Security means don't
run RADIUS over a network where users have access.

 Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html



 


 -
 List info/subscribe/unsubscribe? See
 http://www.freeradius.org/list/users.html


 -
 List info/subscribe/unsubscribe? See
 http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Of accounting data and security

2010-08-09 Thread 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 m...@iterpacis.org 
mailto:m...@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


Re: Of accounting data and security

2010-08-09 Thread Natr Brazell
:)

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 m...@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 m...@iterpacis.orgmailto:
 m...@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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Of accounting data and security

2010-08-09 Thread Alan DeKok
Natr Brazell wrote:
 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.

  The accounting data is sent in the clear on a LAN.  This shouldn't be
a problem.

  If you're sending accounting data across the Internet, use IPSec.
Don't even pretend to use anything else.  RADIUS (and TACACS+) security
is simply not as good as IPSec.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Of accounting data and security

2010-08-08 Thread Natr Brazell
Thanks,

I'm looking into IPSEC at the moment.  I'm curious how TACACS+ does their
encryption?

N

On Fri, Aug 6, 2010 at 4:09 PM, Alan DeKok al...@deployingradius.comwrote:

 Natr Brazell wrote:
  Is there a way to secure the communication between the radius server and
  the NAS especially wrt accounting data?

  IPSec.

  Most NASes implement IPv4, and not much else.  Security means don't
 run RADIUS over a network where users have access.

  Alan DeKok.
  -
 List info/subscribe/unsubscribe? See
 http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Of accounting data and security

2010-08-06 Thread Natr Brazell
Is there a way to secure the communication between the radius server and the
NAS especially wrt accounting data?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Of accounting data and security

2010-08-06 Thread Arran Cudbard-Bell

On Aug 6, 2010, at 12:32 PM, Natr Brazell wrote:

 Is there a way to secure the communication between the radius server and the 
 NAS especially wrt accounting data?

I assume RADSEC will handle Accounting data too, but it's only a draft 
currently. IPSec? Create tunnels between the NAS and the RADIUS server..

-Arran


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Of accounting data and security

2010-08-06 Thread Alan DeKok
Natr Brazell wrote:
 Is there a way to secure the communication between the radius server and
 the NAS especially wrt accounting data?

  IPSec.

  Most NASes implement IPv4, and not much else.  Security means don't
run RADIUS over a network where users have access.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html