[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: auditing - RADIUS
>----------
>From: Ran Atkinson[SMTP:rja@inet.org]
>Sent: Wednesday, April 02, 1997 4:25 PM
>To: Bill Sommerfeld; Stephen Kent
>Cc: ipsec@tis.com
>Subject: Re: auditing
>
>
>Bill,
>
> RADIUS has its own security and does not rely on IPsec, hence there
>is no circular dependency. The question is a good one.
Before anyone plans on using RADIUS, some things should be made clear:
1) All RADIUS communication is in the clear, with the only exception
that user passwords (and the variations of them) are hidden.
2) The U in RADIUS is for USER. Good luck trying to get the RADIUS
working group to add attributes to configure a router/NAS for auditing.
It wont happen. You could argue for auditing on a per user basis, but
is that what you want? and does that make sense?
3) RADIUS accounting is geared toward billable attributes. I don't know
if you would get much support to add IPSec audit trails to the RADIUS
account attributes.
4) RADIUS is shared secret based for all authentication between the
RADIUS client and the RADIUS server. Wow, we just spent all this time
implementing ISAKMP/Oakley with certificates, and now you want to tell
your customers that in order to configure their router to do IPSec
auditing that they'll have to configure a RADIUS server and manage
shared secrets...
(ok I could be biased)
5) The security of RADIUS is questionable when used in environments
where proxying is necessary between RADIUS servers (i.e. roaming users).
As long as all the RADIUS servers are run by the same organization
things are fine. But as soon as it becomes necessary to proxy through a
RADIUS server for which your organization has no control over things go
down hill. A RADIUS server which proxies must decrypt the user password
then re-encrypt it before sending it on to the RADIUS server which does
the final authentication. This means that all passwords are exposed at
the proxies.
6) If the user is setup to do CHAP authentication in RADIUS, there is NO
authentication of the RADIUS client's request when received by the
RADIUS server. This is due to the nature of how the shared secret is
used in RADIUS. Basically when doing PAP the shared secret is used to
encrypt the users password, proof that the RADIUS client holds the
shared secret is shown when the RADIUS server decrypts the password
correctly. When CHAP is done the CHAP response is not encrypted before
being sent to the RADIUS server, therefore there is no proof that the
RADIUS client is who they say they are since the shared secret is not
used in the initial request.
I'll admit that most of the security concerns wouldn't have much to do
with auditing, but are you happy with recommending an IPSec solution
based on a protocol with these characteristics (if you were successful
at getting the RADIUS wg to add the necessary attributes)?
As for the circular reference, if I was running a RADIUS environment
with IPSec capable equipment I think the first thing I would do was
configure IPSec between the clients and the server so I could at least
get protection of the ids and possible authentication (if not proxying)
when CHAP is in use (which I understand to be the majority).
Bye
----
Greg Carter
Entrust Technologies
carterg@entrust.com
>
>