RE: survey of isp security practices

[jbenedict@ca.safenet-inc.com]

I think I can agree with the first two.  Network users and network managers
are fairly distinct.  But aren't the rest (3-6) really authorization (not
authentication) issues? 

Having said that, think they are important 'rights' that need to be
addressed.  

--
James

> -----Original Message-----
> From: David B Harrington [mailto:ietfdbh@comcast.net]
> Sent: Thursday, November 18, 2004 4:49 PM
> To: 'David T. Perkins'; 'Shashi Kiran'
> Cc: 'George M. Jones'; gmj@pobox.com; 'Randy Presuhn';
> opsec@ops.ietf.org
> Subject: RE: survey of isp security practices
> 
> 
> I believe it will be important to separate
> 1) authentication of the security principal for the network management
> protocol
> 2) authorization of the security principal to perform network
> management using the protocol
> 3) authentication of the security principal used for a data carrying
> protocol
> 4) authorization of the security principal to pass data using the
> protocol
> 5) authentication of the security principal used for a data encrypting
> protocol
> 6) authorization of the security principal to encrypt data using the
> protocol
> 
> The pair will be necessary for each protocol used.
> It may be desirable to allow multiple protocols to use the same
> authentication mechanisms and the same authorization mechansisms and
> the same encryption mechanisms, if such can be done without
> compromising security.
> 
> David Harrington
> dbharrington@comcast.net
> 
> > -----Original Message-----
> > From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> > Sent: Thursday, November 18, 2004 4:31 PM
> > To: Shashi Kiran
> > Cc: 'George M. Jones'; ietfdbh@comcast.net; gmj@pobox.com; 
> > 'Randy Presuhn'; opsec@ops.ietf.org
> > Subject: RE: survey of isp security practices
> > 
> > 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
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> > 
> 
> 
>