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

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
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> 
>