Subject: RE: [Isms] charter proposal

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 11 Aug 2005 19:26:48 -0400

I'm surprised to see SSH or TLS called "infrastructure". 

    A. In case of SSH the infrastructure is local accounts.
       All the access control is performed by the host OS.

    B. In case of TLS the infrastructure is a mix of PKI for
       servers and either server-maintained password database,
       or AD/Kerberos for users/clients.

So one needs glue not between SNMP and SSH - but between
SNMP and local accounts (accessible via SSH).

I don't believe this WG can even attempt to solve the problem
of applications, though I acknowledge its (problem's) importance.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B Harrington
Sent: Thursday, August 11, 2005 7:18 PM
To: 'Kaushik Narayan'
Cc: [email-masked]
Subject: RE: [Isms] charter proposal

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]

> -----Original Message-----
> From: Kaushik Narayan [mailto:[email-masked]] 
> Sent: Thursday, August 11, 2005 6:12 PM
> To: [email-masked]
> Cc: 'Randy Presuhn'; [email-masked]
> Subject: RE: [Isms] charter proposal
> 
> 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!
> 
> At 01:12 PM 8/11/2005, David B Harrington wrote:
> >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]
> > > Subject: Re: [Isms] charter proposal
> > >
> > > 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,
> > > >
> > > > 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
> > >
> > > 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
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Isms mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/isms
> > >
> >
> >
> >
> >_______________________________________________
> >Isms mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/isms
> 

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

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

---

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

> From: Blumenthal, Uri [mailto:[email-masked]] 
> 

So are you volunteering to document how this mapping could be
achieved?

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 12 Aug 2005 21:38:42 +0200

<inline>
Tom Petch
----- Original Message -----
From: "Blumenthal, Uri" <[email-masked]>
To: <[email-masked]>; "Kaushik Narayan" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 12, 2005 1:26 AM
Subject: RE: [Isms] charter proposal

A clarification, if you will.  Are you saying that user-authentication (ie
client) is performed by passwords over a encrypted channel (as opposed to
publickey or hostbased, the other two options listed in
draft-ietf-secsh-userauth-27.txt).

Tom Petch
<snip>