Subject: RE: [Isms] charter proposal

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 8 Aug 2005 16:39:36 -0400

[free translation]
- Why are you looking at the ground under this street-lamp?
- Searching for my wallet.
- Did you lose it here?
- No, over there in the darkness.
- Then why are you looking for it here?
- Because here is light.

The purpose of this WG was to address SNMPv3 deployability (or lack of)
by providing an easy way to integrate it with an existing security
infrastructure.

What must be addressed (in the descending order of priority):

1. What existing infrastructure(s) to integrate SNMP with/into. 
2. What credentials that already-deployed infrastructure uses, how it
names principals and how it authenticates them.
2a. What authentication should the new security model use (may or may
not be the same as in 2)?
3. How to map principals between the new security model, the
interfaced-infrastructure, and the rest of SNMPv3.
4. What security mechanisms to use for SNMP traffic protection (and
whether to re-use USM for that).
4a. Required capabilities of those mechanisms, such as taking/providing
to SNMP identity of the principal and traffic protection parameters.

I personally find the decision to use SSH rather irrelevant. The WG must
find satisfactory answers to the first three questions first.

E.g. somebody wants to integrate with Kerberos. How will SSH help him?
Somebody else needs RADIUS. How are his problems (configuring user
database, supplying credentials, etc) solved with SSH? Yet another
person wants PKI... 

So don't tell me what protocol you'll be using - tell me how you'll
provision (and maintain the database of) identities and credentials. And
tell me how you'll map those identities onto something usable in Access
Control. That's all that matters, the rest is mostly BS (and you
probably know it).

P.S. Any combination of mechanisms/infrastructures can work - the only
difference is how expensive it will be to implement/deploy/operate.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 10 Aug 2005 18:06:30 -0700

Hi -

I whole-heartedly concur with Uri's comment.

Randy

----- Original Message ----- 
From: "Blumenthal, Uri" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 08, 2005 1:39 PM
Subject: RE: [Isms] charter proposal

[free translation]

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Aug 2005 12:34:44 +0200

Randy,

Could you and Uri please comment on what is necessary to improve
Juergen's doc, which seems to me to cover a lot of ground that URI
refers to?

Eliot

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Aug 2005 08:50:12 -0700

Hi -

> From: "Eliot Lear" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, August 11, 2005 3:34 AM
> Subject: Re: [Isms] charter proposal
>
> Randy,
>

I can't speak for Uri, but I think the heart of the matter is that there doesn't
seem to be a "mandatory to implement" integration with any of the other
infrastructures mentioned in the draft (e.g., Kerberos or Radius), or the
WG charter (e.g. TACACS+, X.509 Certificates, LDAP, Diameter).
The references to any sort of AAA are very generic, (probably by design,
knowing the authors) but we need to nail down just what this stuff
talks to in order to know how to answer the fundamental question:
Does this proposal provide sufficient integration with existing infrastuctures
to satisfy the operational needs that triggered formation of this WG?

Randy

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 11 Aug 2005 16:12:27 -0400

Hi,

I think the issues under discussion may actually be missing the point
somewhat, or hitting the nail on the head, depending on how you look
at it. 

Having worked for Enterasys first in the management application side,
and then in the equipment side, I see a fundamental problem. 

Gene mentioned that SNMPv3 is supported in a bunch of devices, and I
agree with that. While equipment vendors have provided varying degrees
of support, most of the major equipment vendors do support SNMPv3
messaging and the MIB modules to support SNMPv3.

The place where SNMPv3 really isn't supported is in the management
applications. I believe this is the result of two major impacts of
SNMPv3 on management applications. 

First, while networking equipment has long supported remote monitoring
and some configuration via SNMP, management applications have
**never** allowed remote monitoring and configuration via SNMP. SNMPv3
added a MIB to management applications; in SNMPv1, the MIB only
existed in the managed equipment. It is a very foreign concept to
allow some other entity to modify the operating environment,
especially the security parameters, of the application from the
network side of things. And I don't see applications vendors jumping
up and saying, "oh, please let me open that can of worms for my
programs!"

Second, SNMP defines a user-interface via MIB modules for equipment,
but the user-interface for management applications is very different.
To add real support for the concepts of SNMPv3 could require lots of
changes to code and internal APIs to pass the necessary parameters
from the user interfaces for client implementations, to access the
server functionality, through the program logic, and into the database
interface to remote management protocols and, ultimately, the SNMP
stack. In addition, if access control is applied at the managed
device, then the applications should also honor the access controls,
so a MIB module accessible to "lear" but not "dbh" on a remote device
isn't exposed to "dbh" through the management application's database.
Adding support for SNMPv3 concepts and applying SNMPv3 access control
is a huge cost for application vendors.

So the problem isn't just about leveraging the AAA support already
supported in the equipment; it's about providing an authentication and
authorization solution that will be utilized by application vendors,
reflected in application user interfaces, and applied to user views
into application databases (as mirrors of the managed equipment
databases).

So maybe we should be having serious discussions about application
frameworks like .NET and J2EE, and their security infrastructures, and
how we can leverage their security infrastructures for securing both
the client applications and the n-tier server  functionality of
network management. By n-tier functinoality, I am thinking of
application databases, the proxy layer that converts from business
logic requests to SMI varbinds, the communication layer between the
srver and the remote SNMP engine, and the associated remote MIBs that
connect from the SNMP protocol to the underlying instrumentation. Web
services has already been dealing with this type of archoitectural
breakdown.

I'm not suggesting using http and web services, but leveraging the
security infrastructure that correlates user authentication at the
client application to the database access routines, and to remote
procedure calls into remote databases.

I think that discussing SSH vs RADIUS vs PKI vs local accounts is
thinking too much about the protocols, and not enough about the
high-level problem of leveraging security infrastructure in complete
network management **systems**.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Thursday, August 11, 2005 11:50 AM
> To: [email-masked]

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 11 Aug 2005 15:11:41 -0700

Hi David,

Sorry for my ignorance but I am not sure how the discussion of
management of NMS applications via SNMP is relevant to ISMS.
SNMP is not used for application management since there are
already standards that provide richer and more tighter integration
with applications. This includes Java standards such as JMX and
CIM and WSDM. I agree that we need to provide support for
common authentication systems between the SNMP/NetConf/CLI
and NMS apps but I am not sure how that is related to the NMS
apps being managed via SNMP.

SNMP is important for what is used, i.e. Inventory, Performance
and Fault monitoring of networks and it is important to have common
identity and authentication mechanisms across the management
domain, this includes the protocols used manage devices and user
access to the NMS.

To achieve that goal, the discussion of protocols such as RADIUS and TACACS+
is very essential in ISMS since these protocol servers work as proxies
to enable unification of identity and authentication stores. Most
AAA servers support integration into a variety of back-end identity
and authentication systems thereby allowing organizations to use a
single identity and credentials across a variety of domains such as
applications access including network management apps, network
access and device access. We have been fairly successful with
using AAA servers as a proxy to Active Directory, LDAP servers,
Token Servers and NIS+

That's the reason our initial focus with EUSM was to make sure that we
enable SNMP authentication to integrate with a RADIUS server.

regards,
  kaushik!

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Aug 2005 15:44:36 -0700

Hi -

> From: "Kaushik Narayan" <[email-masked]>
> To: <[email-masked]>
> Cc: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Thursday, August 11, 2005 3:11 PM
...
> management of NMS applications via SNMP is relevant to ISMS.
...

When an NMS uses SNMPv3 to communicate with some managed
system, it does so on behalf of a user.  For the SNMP engines
at both ends of this interaction, it was intended that the users
and their keys would managed through the USM MIB, though
the specifications don't preclude that information arriving there
via some mechanism other than SNMPv3.   Some NMS developers
had a really hard time grasping that some of the parameters of
*their* application might be managed, just like those of anything else.

...
> using AAA servers as a proxy to Active Directory, LDAP servers,
...

I think we're agreeing.  Specify how it's supposed to work with some
small N that will cover most of the operator requirements, and make
one mandatory to implement.

Randy

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 11 Aug 2005 19:17:56 -0400

Hi Kaushik,

USM expects shared key management to be done via SNMPv3, and
application vendors don't allow their applications to be managed via
SNMP. So while you can try to synchronize the keys across multiple
managed devices using SNMP, you cannot synchronize the keys used by
the applications using SNMP.

Changing to a different security model, you might be able to
synchronize the keys across multiple managed devices using RADIUS, or
TACACS+, or Kerberos, or PKI, but can you manage the keys used by the
NMS applications? 

I'm working on writing a proposal to provide the glue between SNMP and
SSH, because SSH is used for accessing the CLI on many vendors'
network-equipment products, but I'm not sure how many SNMP management
application vendors support using SSH to talk to the CLI, and how many
applications use the SSH user/key infrastructure to authenicate the
users of the applications. So while we might enable updating user/keys
across multiple devices, how many NMS applications will support such
an approach?

I would like to see a concrete proposal of how NMS applications should
be updated to support a common authentication infrastructure like SSH
or RADIUS, and the implications of utilizing such a proposal within an
NMS application like HPOV.

So far, the discussion seems to be mostly about engine-to-AAA issues,
not application-impact considerations. If the SNMP stack needs to
provide CHAP credentials to authenticate the user, the application is
going to need to prompt the user for his credentials, and track the
sessions and so on. How will this impact the application? 

Do most NMS applications currently support going to a AAA server to
authenticate its users now? Which ones do this? How do they do it? If
your applications do this now, can you document how this is done so we
can standardize the approach, and encourage other NMS applications to
use the same approach?

David Harrington
[email-masked]

> From: Kaushik Narayan [mailto:[email-masked]] 
> Sent: Thursday, August 11, 2005 6:12 PM
> To: [email-masked]
> Cc: 'Randy Presuhn'; [email-masked]
> > > to satisfy the operational needs that triggered formation of
this
> >WG?

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 11 Aug 2005 16:43:04 -0700

Hi Dave,

Please find my reply inline.

>the applications using SNMP.

I am not sure about what you mean by "keys used by applications". I
am assuming you are referring to keys used to protect communication
channels used by the applications such from a web browser/client or between
application servers in a distributed model. Well most of these keys tend
to be ephemeral and have no co-relation to the principal accessing the
application. The prevalent model is to tunnel application protocols such
as HTTP, IIOP and JMS over TLS. The TLS channel is authenticated via
the server cert and clients are authenticated via username/password. This
is similar to what would happen if you login to bank account online.
(there are very few applications that support client side certs except in
cases where clients are a system entity such as an OSS system).

In terms of integrated security it is important that the same username/password
is used south bound from the NMS applications going to the device as
used in gaining access to the NMS itself.

>TACACS+, or Kerberos, or PKI, but can you manage the keys used by the

Again I think the key management is a bit of a red herring unless we are
talking about different "keys" here.

>across multiple devices, how many NMS applications will support such

Our NMS applications do use SSH to access CLI on our devices and
all our authentication is user based. So by pointing both the device
and the NMS to the same AAA server, we can essentially use the
same username/password provided during NMS login going down from
the NMS to the device. There are however exceptions since that might
not be desired in some cases, there might be a need to use a pre-configured
system account to communicate with devices.

>can standardize the approach, and encourage other NMS applications to

Most of our NMS applications support the use of AAA for login to the NMS
and there is very commonly used by a lot of our customers. The NMS
behaves like a standard RADIUS or T+ client.

regards,
  kaushik!

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 11 Aug 2005 17:29:39 -0700

Hi -

> Sent: Thursday, August 11, 2005 4:43 PM
...
> I am not sure about what you mean by "keys used by applications". I

The USM authentication and privacy keys.

...

No.  The keys used for SNMPv3.

> used in gaining access to the NMS itself.

USM tries to avoid that through key localization.  Otherwise, compromise of
a single managed device would compromize all other devices accessible
by that user.

...

I fail to see how key management is a "red herring" when it is one of the
key complaints about the deployability of SNMPv3.

Randy