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

RE: survey of isp security practices

At 11:12 AM -0500 11/18/04, David B Harrington wrote: 
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.

Understood. Let me pose a question to you as well as the OPSEC group, with special reference to the OPSEC charter. Some years ago, during the IPng effort, there were a set of very interesting, short papers on industry or technology area requirements for IPng. They had the flavor both of an applicability document and a white paper on future applicability/requirements.

Is there scope for a short OPSEC paper or papers documenting some of these potentials? In other words, a collaboration that says "here are SP needs, and here are ISMS and/or per-user authentication approaches. This might be a roadmap about how they come together."


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.


Is the sort of document I briefly mentioned a starting point?


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