RE: survey of isp security practices

["David T. Perkins" <dperkins@dsperkins.com>]

HI,


In the below, it seems to point out a difference in
use of authentication. That is, authentication to be
used for allowing management of the network elements,
and the authentication to be used for access to carry
data traffic over the network.

Is the ISP security practices going to make that
distinction?

On Thu, 18 Nov 2004, Shashi Kiran wrote:

> > -----Original Message-----
> > From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] 
> > Sent: Thursday, November 18, 2004 4:12 AM
> > To: ietfdbh@comcast.net
> > Cc: gmj@pobox.com; 'Randy Presuhn'; opsec@ops.ietf.org
> > Subject: Re: survey of isp security practices
> > 
> > 
> > 
> > On Nov 17, 2004, at 1:43 PM, David B Harrington wrote:
> > 
> > > Hi George,
> > >
> > > I agree with Randy that user, access control, and key 
> > management need 
> > > to be included in this discussion. Assuming RADIUS will 
> > "handle it" is 
> > > insufficient.
> > >
> > > What happens when RADIUS authentication is not accessible 
> > because of 
> > > network problems? Is there a fallback to local authentication?
> 
> 
> > In the operational environment that I am most familiar with, 
> > yes, there is fallback to local authentication...a single account.
> 
> 
> 
> > Does anyone have examples of large nets where more than a few 
> > local users are maintained across all devices ?
> 
> Another instance of a network-level issue is the case where a provider has
> managed VPNs with a centralized shared RADIUS between enterprises, and there
> was a possibility for subscribers belonging to one VPN to switch between
> VPNs or access a different service profile, by introducing certain VSAs or
> source-spoofing, and cause security breaches. In this case access controls
> checks need to be tightened on the router nodes or PEs where subscribers are
> terminating, since the RADIUS by itself cannot handle it. Not sure if you
> want to cover such scenarios here.
> 
> > > How are the local authentication keys distributed and managed?
> > 
> > 
> > Generated and maintained offline...can differ per device/per 
> > class of device ... access to per-device fallback passwords 
> > controlled other globally available authentication and 
> > authorization means. That's one way to do it.
> > 
> > Distribution is indeed a problem.
> > 
> > >
> > > RADIUS can provide per-user authorization; what happens 
> > when RADIUS is 
> > > not available? Is there a fallback to local per-user authorization?
> > 
> > See above.
> > 
> > 
> > > How are the local per-user authorization rules managed (created, 
> > > deleted, etc.)?
> > >
> > > You mention "per-command" access control.
> > > Is per-command the only type of access control desired?
> > > What about access to different subsets of information, such as 
> > > writable MIB module data, security configuration data, sensitive 
> > > directory data? Does RADIUS provide enough info for 
> > controlling access 
> > > to data subsets, when a user is permitted to modify some things but 
> > > not others?
> > > What happens in a local-authorization fallback scenario?
> > >
> > > Some protocols provide for encrypted messaging, such as SSH and 
> > > SNMPv3. Does RADIUS provide authentication for the encryption 
> > > protocols? How are the encryption keys managed?
> > > How are the keys managed in a local-authnetication fallback 
> > scenario?
> > >
> > > Without answering some of these questions, the discussion is really 
> > > incomplete.
> > 
> > Can you phrase those in the form of capabilities ("supports 
> > fallback to local authentication in the event that network 
> > based authentication mechanisms are unavailable") ?  If so, 
> > we can discuss.
> > 
> > Thanks,
> > ---George
> > 
> > 
> > 
> > 
> > 
>