[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: survey of isp security practices
Hi Howard,
1) Let me clarify. The purpose of the ISMS WG is to develop security
subsystems for SNNPv3 that will use existing security infrastructures
such as Radius. The architecture being used for ISMS is clearly
defined in RFC3411 and RFC3412, and is a Full Standard (STD62). The
architecture is not still under development. Development of additional
security subsystems are being discussed within that architecture. I
agree that the new proposals are out of scope for a best current
practice document. I don't think it is anybody's intention to try to
discuss those proposals within the best current practices survey or
device capabilities document.
2) The operator community has complained loudly that the IETF NM
community has ignored their needs for years, and developed protocols
that are not useful in "real implementations". SNMPv3 was designed
deliberately to provide per-user authentication and access control,
even during a fallback scenario, at the request of people who
purported to speak for the operator community. George mentioned that
his environment has one local user for fallback. Do other operators
agree that having only one local user is the best current practice? Is
per-user authentication and access control during normal operation
and/or fallback not needed or wanted by the operator community
represented in this WG? What is the best current practice for
distributing the keys for the local user(s)?
As a member of the IETF NM community, I would like to have this WG
identify the best current practices and the device capabilities
necessary to support those practices. That would at least ensure that
we understand the best available approach to these difficult issues,
and hopefully all vendors will move to support at leaat that low bar.
Then WGs like ISMS can work to build upon that solid base.
3) We believe "best current practices" regarding authentication,
authorization, and key distribution SHOULD be discussed. The ISMS WG
has had difficulty getting answers about "best current practices"
regarding security infrastructures, since there appear to be a wide
range of implementations that use different security infrastructures,
and few operators participate in the ISMS discussions. The ISMS effort
(and other IETF network management efforts) would be helped immensely
to have the best current security practices documented.
The OPSec WG is chartered to "codify knowledge gained through
operational experience about feature sets that are needed to securely
deploy and operate managed network elements", so such discussion
should be in scope.
My $.03
David Harrington
dbharrington@comcast.net
co-chair IETF SNMPv3 WG, concluded
> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On
> Behalf Of Howard C. Berkowitz
> Sent: Thursday, November 18, 2004 10:23 AM
> To: opsec@ops.ietf.org
> Subject: RE: survey of isp security practices
>
> At 9:26 AM -0500 11/18/04, David B Harrington wrote:
> >Hi Howard,
> >
> >Can you identify which mail you are responding to, so we can
> understand
> >your comment better?
> >Which architectural models still under development are you
referring
> >to?
> >
> >David Harrington
> >dbharrington@comcast.net
>
> A couple of things, cited below. I would suggest that at
> least the current practice document contain, in the
> introduction, the caveat that it refers to real
> implementations. The more general requirements document could
> carry a "softer" caveat, indicating it would only identify
> clear requirements for which there are no available tools.
>
> At 10:42 PM +0000 11/17/04, Christopher L. Morrow wrote:
> >On Wed, 17 Nov 2004, George Jones wrote:
> >
> >> On Sun, 14 Nov 2004 18:54:58 -0800, Randy Presuhn
> >> <randy_presuhn@mindspring.com> wrote:
> >> > Hi -
> >> > > From: "Merike Kaeo" <kaeo@merike.com> > > To:
> >> <opsec@ops.ietf.org> > > Sent: Tuesday, November 09, 2004
> 4:03 AM >
> >> > Subject: survey of isp security practices > ...
> >> > > 4. Authentication / Authorization
> >> > In this, or the updated structure, any discussion of
> >> authentication > and authorization would be incomplete if
> it didn't
> >> address user, > access control list, and key management.
> >>
> >> The scope here is core network device capabilities.
> >> I would submit that, given protocols such as RADIUS (Diameter,
> >>TACACS)
> >> that user mangement is largely an external issue (it
> happens on the
> >> RADIUS server, etc). The important bit is that the
> device needs to
> >> be able to talk to the [radius] server, be sure which
> server it's
> >>talking
> >> to, and be able to get authentication and authorization data
(per
> >>command...your
> >> "access control lists ?") from the server.
> >
> >managing local users on devices is non-scalable and a dead art...
as
> >George said.
>
>
> At 3:05 PM -0800 11/17/04, David T. Perkins wrote:
> >On Wed, 17 Nov 2004, Christopher L. Morrow wrote:
> >...
> >> managing local users on devices is non-scalable and a
> dead art... as
> >> George said.
> >>
> >
> >That is one of the reasons for creating a new "security model"
> >for SNMPv3. The SNMPv3 term "security model" is includes:
> >1) the means for authenticating "security principals"
> >2) how message integrity (message modification, replay,
> > and binding with a security principal) is accomplished
> >3) how message confidentiality (encryption) is accomplished
> >
> >The only currently defined security model for SNMPv3 is the "User
> >Security Model" (USM), and it is a "local user"
> >data base called by the SNMPv3 the local configuration
> datastore (LCD).
> >
> >The ISMS WG is working on a new security model for SNNPv3
> that will use
> >existing security infrastructures such as Radius.
>
>
> >
> >
> >> -----Original Message-----
> >> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On
> Behalf Of
> >> Howard C. Berkowitz
> >> Sent: Wednesday, November 17, 2004 6:25 PM
> >> To: opsec@ops.ietf.org
> >> Subject: Re: survey of isp security practices
> >>
> >> Might I observe that a document called "Survey of ISP Security
> >> Practices" isn't necessarily a logical place for
> functions for which
> >> the architectural models are still under development?
> Perhaps there
> >> is a place for a new document "Requirements for (new) ISP
> Security
> >> Practices", but the value of the current one seems to be
> what people
> >> actually do.
> >> If they do things that have problems with scalability, it
> still may
> >> be relevant to note the technique, its limitations, and move on.
> >>
> >>
>
>
>