Subject: [Isms] Charter proposal

From: "David B Harrington" <[email-masked]>
Date: Tue, 2 Aug 2005 13:05:47 -0400

Hi,

As Uri pointed out today, we have not determined whether our approach
going forward should establish a "session" to amortize the security
overhead across multiple SNMP messages. Is that something we should be
planning on when writing the SSH proposal and updating the TMSM
document? (yeah, I know we haven't agreed on the charter yet, but
should we be addressing this issue in the proposals being prepared?)

Is anybody willing to contribute some text about how the session
concept will fit within a TMSM environment, and how that fits within
the SNMPv3 architecture so a session-based security model can coexist
with non-session security models, such as USM?

David Harrington
[email-masked]

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

---

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 3 Aug 2005 21:33:24 -0700

Hi David,

I stand corrected.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]]
> Sent: Wednesday, August 03, 2005 2:09 PM
> To: 'McDonald, Ira'
> Cc: [email-masked]
> Subject: RE: [Isms] charter proposal
> 
> 
> Hi Ira,
> 
> I totally disagree with your analysis. 
> 
> I think we have accomplished a lot. Not as much as I would have liked,
> but a lot nonetheless. We have written multiple proposals, reviewed
> those proposals, convened an official review team and published a
> fairly detailed analysis of the proposals, discussed the ramifications
> of the architectural differences of the proposals, eliminated some
> proposals, chosen a general direction for focus (use of encapulating
> protocols to carry SNMP messages), cleaned up the initial proposal,
> identified and discussed many technical issues relative to the TMSM
> approach, had a BEEP/TMSM proposal written and reviewed, and started
> work on an SSH/TMSM proposal - and we have seven editors willing to
> commit to working against a short deadline. I see lots of agreement on
> direction, and even though some industry segments wish we had selected
> different directions, rough consensus on the chosen direction. I wish
> some of the other WGs I've been in had made this kind of progress.
> 
> As far as this being comparable to SNMPv2 years, no way! During those
> years we suffered through tremendous ego battles as responsibility for
> designing solutions shifted from the "big four" players to the whole
> SNMP community; abandoned a Proposed Standard when we realized the
> design was completely non-viable for application vendors; we suffered
> the segmentation of the community into two major "camps"; and we
> suffered through an imposed shutdown of the WG and ALL network
> management development work, not because the WG couldn't reach
> consensus or finish documents but to avoid the constant acrimonious
> flame wars between the camps. We are seeing none of the ego battles or
> flame wars in this WG, and given the progress we have manifested, I
> think it unlikely this WG will be shutdown soon.
> 
> David Harrington
> [email-masked]
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of McDonald, Ira
> > Sent: Wednesday, August 03, 2005 12:04 PM
> > To: 'Wijnen, Bert (Bert)'; Eliot Lear; [email-masked]
> > Cc: Margaret Wasserman; Andy Bierman; Sam Hartman; [email-masked]
> > Subject: RE: [Isms] charter proposal
> > 
> > Hi,
> > 
> > With much respect to all people involved, I note that nearly
> > a year has passed since this working group rushed into work.
> > And the divisions and disagreements are, if anything, worse.
> > 
> > If people with strongly held opinions on specific directions
> > would sit down and write REALLY complete proposals, maybe this
> > effort would progress.
> > 
> > As a working group, it feels a lot like the many years SNMPv2
> > debacle.
> > 
> > And of course, NOTHING was decided in Paris.  This is a chartered
> > IETF working group.  Rough concensus on the mailing list is the
> > ONLY place that decisions get made.
> > 
> > Cheers,
> > - Ira
> > 
> > Ira McDonald (Musician / Software Architect)
> > Blue Roof Music / High North Inc
> > PO Box 221  Grand Marais, MI  49839
> > phone: +1-906-494-2434
> > email: [email-masked]
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]]On
> > > Behalf Of Wijnen, Bert (Bert)
> > > Sent: Wednesday, August 03, 2005 10:26 AM
> > > To: Eliot Lear; [email-masked]
> > > Cc: Margaret Wasserman; Andy Bierman; Sam Hartman; [email-masked]
> > > Subject: RE: [Isms] charter proposal
> > > 
> > > 
> > > w.r.t.
> > > > Also, all decisions at IETF are confirmed by the mailing 
> > list.  I am
> > > > saying that this is one we ought not confirm.  Instead, we
> should
> > > > continue with draft development and compare approaches, 
> > > > particularly in
> > > > light of the broader context, and then make a decision.
> > > > 
> > > > The ADs have made it clear that they want us to finish, and have
> > > > suggested that perhaps an interim meeting might help.
> > > 
> > > First, in this case I am not an AD for the WG. I am SNMP 
> > (or OPS area)
> > > advisor to the WG. So I do not play AD role here.
> > > 
> > > Second, I did indeed make that suggestion, and stated that such
> > > would be acceptable to me, but that I rather prefer a decision
> now.
> > > 
> > > I do not recall that Sam in fact agreed with the suggestion. 
> > > I'd expect
> > > he wants to see more discussion on the list w.r.t. confirming the
> > > decision that seemed obvious in the f2f WG session. Sam can
> > > speak up if I am mis-representing him.
> > > 
> > > Let me add (for repeated clarity):
> > > The only reason I even though of this is because some were asking
> > > for another delay to Vancouver (i.e extend yet one more IETF
> meeting
> > > as we have had so many before). An interim would give some extra
> > > time (max september in my view) to better discuss the choice
> between
> > > the shortlist (ssh and beep). But it at the same time REQUIRES
> > > commitement from all WG members to do a lot os serious work within
> > > the next 5-7 weeks and to invest not only time but also travel
> > > to an interim. In other words a lot of extra work in order to get 
> > > a little bit of extra time. 
> > > 
> > > Again, it was a suggestion that I can live with, but which is up
> to
> > > the AD (Sam) to approve.
> > > 
> > > Bert
> > >

---

From: "Nelson, David" <[email-masked]>
Date: Mon, 8 Aug 2005 12:59:29 -0400

David Harrington writes...

> SSH provides an authentication of the user via some sort of
> authetication mechanism.
> SNMP does not care what the underlying mechanism is that SSH uses,
> only that it trusts SSH to do the job effectively.

That sounds like a protocol design discussion.  I thought we were having
WG charter discussion.

If SSH already provides authentication that meets the *current* charter
requirements, i.e. authentication that leverages both local and remote
AAA of the sorts that operators have deployed, then it is probably
sufficient to worry about designing an interface between SNMP and SSH.
My comment is intended to signify that the "if" at the beginning of the
previous sentence represents a mandatory pre-requisite.

Phrasing this differently, SNMP may not care what the underlying
mechanism is, but the operators using SNMP are very likely to care.

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 8 Aug 2005 20:36:15 +0200

Apologies for the sloppiness of my wording; what I was trying to convey was
more like

Thus the authentication of the principal which invokes the Command Generator in
an SNMPv3 engine which is using SSH as a secure transport will (most likely) be
done by secsh-userauth, for which user (identified by UTF8 string)
authentication
by public key is REQUIRED and authentication by user password (with transport
level encryption) and or by host (dns name, IPaddress) public key is OPTIONAL.

but I expect I have not covered all the bases:-)

Tom Petch

----- Original Message -----
From: "David B Harrington" <[email-masked]>
To: "'Tom Petch'" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 08, 2005 3:14 PM
Subject: RE: [Isms] charter proposal
>
> > I agree; we should specify the SSH options that are
> > appropriate but no more than
> > that.  Thus the authentication of the Command Generator will
>
> In writing an SSH proposal, it is my intention to authenticate the
> user, not the Command Generator. Authenticating only the command
> generator entails a tremendous loss of granularity in identifying the
> princiapl, and I do not consider that change of granularity to be in
> high demand by the SNMP community, nor do I think there is consensus
> of this WG that such a change should be made.
>
> David Harrington
> [email-masked]
>

---

From: "Golovinsky, Eugene" <[email-masked]>
Date: Thu, 11 Aug 2005 07:36:55 -0500

My 2 cents of support to that notion.

The fundamental problem with SNMPv3 is not security, but "deployability"
and usability. Very few people in reality are using v3, although a lot
of devices provide support for it. There is no really turn key operation
and IT departments can not afford anymore army of admin staff doing
manual configuration labor. SSH is hardly a solution to this issue. As
long as we do not provide meaningful integration with already deployed
infrastructure and easy initial deployment/configuration SNMPv3 will
remain extremely secure :-), simply because nothing is going to be
exposed through it :-)

Over last 4 years I've been watching our customers becoming less and
less curious about SNMPv3, to the point that almost nobody is asking
about it anymore. What does it tell you? Is security really an issue? 

--Gene

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Randy Presuhn
Sent: Wednesday, August 10, 2005 8:07 PM
To: [email-masked]
Subject: Re: [Isms] charter proposal

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

---

From: "Golovinsky, Eugene" <[email-masked]>
Date: Thu, 11 Aug 2005 15:39:26 -0500

YES!!!!!!!
Sorry, I could not contain myself:-) I absolutely agree with this
clarification.
Discussion about transports are not solving the real problem, but rather
trying to address symptoms.

Thanks, David!

--Gene

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David B Harrington
Sent: Thursday, August 11, 2005 3:12 PM
To: 'Randy Presuhn'; [email-masked]
Subject: RE: [Isms] charter proposal

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]

> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Thursday, August 11, 2005 11:50 AM
> To: [email-masked]
> > From: "Eliot Lear" <[email-masked]>
> > To: "Randy Presuhn" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Thursday, August 11, 2005 3:34 AM
> > 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?

---

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

Naw, I'm outta here. 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Thursday, August 11, 2005 7:38 PM
To: Blumenthal, Uri; 'Kaushik Narayan'
Cc: [email-masked]
Subject: RE: [Isms] charter proposal

> From: Blumenthal, Uri [mailto:[email-masked]] 
> 
> So one needs glue not between SNMP and SSH - but between
> SNMP and local accounts (accessible via SSH).

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

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 11 Aug 2005 18:28:37 -0700

Hi Randy,

I am sorry I was completely confused about what we were discussing.

I understand USM, key localization and why we need key management
in SNMPv3. From David's message, it seemed that David was referring
  to "keys used by applications" which I understood to be a set of keys
that applications use for their own protection and have nothing to do
with SNMPv3.

That's reason I wasn't sure about need to synchronize keys on the agent
to keys "used" by the application.  In case David was referring to how we
could get multiple NMS applications to share keys that use to talk SNMP agents,
that really is an application implementation and in most cases we should
be able to share the keys in case there is a common SNMP transport
infrastructure shared by these applications. In large part most NMS 
applications
including HPOV have the capability to refer to a shared local credential store.

regards,
   kaushik!

>Hi -
>
> > From: "Kaushik Narayan" <[email-masked]>
> > To: <[email-masked]>
> > Cc: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> > Sent: Thursday, August 11, 2005 4:43 PM
>...
> > At 04:17 PM 8/11/2005, David B Harrington wrote:
> > >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.
> >
> >
> > I am not sure about what you mean by "keys used by applications". I
>
>The USM authentication and privacy keys.
>
> > 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
>...
>
>No.  The keys used for SNMPv3.
>
> > 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.
>
>USM tries to avoid that through key localization.  Otherwise, compromise of
>a single managed device would compromize all other devices accessible
>by that user.
>
> > >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?
> >
> >
> > Again I think the key management is a bit of a red herring unless we are
> > talking about different "keys" here.
>...
>
>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
>
>
>
>

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 15 Aug 2005 10:52:09 -0700

Gene,

I suspect that your customers may have concluded that the security gain
of deploying SNMPv3 was not justifiable due to the increases in
deployabilty expenses. However, there are likely to be a large number of
differing reasons underlying that common conclusion. Perhaps some
customers felt that their existing perimeter defenses made SNMP security
redundant? Perhaps some felt that SNMPv3 security was much less secure
than could be fiscally justified by the pricetag of deploying it?
Certainly, that is the motivation underlying the deployments with which
I am associated. Regardless, tying ISMS security to existing
authentication infrastructures SHOULD (if done correctly) drastically
change that cost equation by making the infrastructure cost of deploying
SNMP security be significantly lessened. Thus, if ISMS does its job
correctly, there should be a significantly lessened pricetag to
deploying SNMP securely.

--Eric

-----Original Message-----
From: Golovinsky, Eugene [mailto:[email-masked]] 
Sent: Thursday, August 11, 2005 5:37 AM
To: Randy Presuhn; [email-masked]
Subject: RE: [Isms] charter proposal

--Gene