[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: auditing

Before we go too far down this "RADIUS for auditing" path, please note
that

1.	RADIUS is _not_ designed to carry this kind of information
2.	RADIUS accounting provides only weak client authentication;
RADIUS itself provides _no_ client authentication except that provided
by checking the client IP address
3.	RADIUS Accounting _only_ sends messages at the beginning and end
of sessions (although this is under discussion)
4.	RADIUS Accounting is not (according to Mike O'Dell, never will
be) an IETF standard protocol 
5.	RADIUS does not scale due to its shared-secret form of security
and there are no plans to incorporate either stronger or more scalable
forms of encryption.  In fact, RADIUS over IPSEC has been discussed at
length recently on the RoamOps list as a possible means of solving this
scalability problem
6.	There is no provision in RADIUS  for any data encryption

Basically, this is _not_ a good idea (IMHO).  As illustration (though
anecdotal) of this: I was prohibited (by a non-competition agreement)
from doing any security work from 1/96-1/97.  My former employer was
serious about enforcing this agreement, to the point of sending me a
registered lawyer letter just because I published an Internet-Draft the
title of which contained the word "authentication".  In this period of
time, I developed (with the blessing of said employer) two RADIUS
servers.  Tell you anything?

	-----Original Message-----
	From:	Ran Atkinson [SMTP:rja@inet.org]
	Sent:	Wednesday, April 02, 1997 2:31 PM
	To:	Bill Sommerfeld; Ran Atkinson
	Cc:	ipsec@tis.com; Stephen Kent
	Subject:	Re: auditing 


	--- On Wed, 02 Apr 1997 16:47:55 -0500  Bill Sommerfeld
<sommerfeld@apollo.hp.com> wrote:

	> >   RADIUS has its own security and does not rely on IPsec,
hence there
	> > is no circular dependency.  
	> 
	> Of course, this means that outbound (and inbound) logging
traffic
	> needs to be treated the same way as key management traffic,
bypassing
	> any ipsec policy engine which might trigger the creation or
use of a
	> security association...
	> 
	> 					- Bill

	OR it means that the IPsec Policy Engine knows to bypass RADIUS
	traffic around IPsec -- as part of the Policy Engine's knowledge

	of the IPsec policy for that system.

	Bypassing might be quite reasonable for RADIUS since RADIUS has
its own 
	built-in security.  I suspect that there are in fact N
applications where 
	one doesn't want to apply IPsec on top of some other
higher-layer 
	security mechanism (SSH, SSL, and PEM, provide potential
examples of this).

	Ran
	rja@inet.org
Follow-Ups: