Subject: Re: [Isms] Evaluation status [and more]

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 26 Jan 2005 16:48:02 -0800

Hi -

> From: "David B Harrington" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, January 26, 2005 4:15 PM
> Subject: RE: [Isms] Evaluation status [and more]
...
> Note that RFC2576 is obsolete; it has been replaced by RFC3584. The

A stale cache error on my part, but it doesn't affect my point.

> document has gone from standards-track to being simply a BCP. So the
> "requirement" that requests be handled as noAuthNoPriv doesn't carry
> the same weight as if it were a standard. That requireent is there
> because SNMPv1 messages have no confidentiality protection. We could
> certainly generate a new document, or an appendix to the proposed
> security model, that could override RFC3584 for coexistence between
> SNMPv1 and the new security model, if the new security model could
> provide adequate message secuirty to justify the continued use of the
> community-authentication model, or could utilize the community field
> of the SNMPv1/v2c message format to transport an authenticatable user
> identity (e.g. via SNMPv2a) for use by VACM. So I don't agree that
> anything other than public would need to be handled through SNMPv3.

We're actually in agreement: if one wants to use SNMPv1 over a secure
transport that provides real authentication services, one would need to
define a new security model to make use of it, since authentication doesn't
have much of a point until teamed up with an access control model of some kind.

> -- the need to modify agents
>
> I agree that any new security model might require updating agent code.
>
> I think the real issue for operators is having to upgrade their whole
> systems, not just their legacy agents. As far as I have been able to
> determine, most equipment vendors already support SNMPv3-capable
> agents in new products; the real problem is that most management
> applications do not. Last I checked, HPOV, CA UniCenter, Tivoli, BMC
> Patrol, and Spectrum (the five leading multi-vendor platforms last
> time I checked) all did not support native SNMPv3; many offer a proxy
> via an SNMPv3-daemon, but no direct support for SNMPv3 in their main
> device-communications logic.

Do we have any reason to believe that they would overcome their
inertia and disregard for customers' security (or whatever else has
motivated their inaction) and implement whatever comes out of this effort?

> So I think the problem is upgrading the operators' systems of
> interoperable managers and agents to support SNMPv3. If an SNMP
> security model (or security approach, if you will) could secure
> SNMPv1/v2c messages then it could be easier for operators to secure
> their SNMP systems, even without upgrading their managers to SNMPv3.

This is a part that I don't quite understand.  A management application
would need to provide some bits to the SNMP Engine & transport in
order to get them to put the correct user authentication bits onto the wire.
How is the reward/effort/risk going to be substantially different for them
from what it would have been to put SNMPv3 in?

> If a new SNMP security approach utilized existing security
> infrastructure already co-resident with the legacy agents, such as SSH
> or SSL/TLS, to secure the messages, then living a while longer with

Even if an existing box has SSH code in it, if the SNMP code doesn't
call it, getting it to do so means a few firmware/software version.

> the SNMPv1/v2c message format and a lack of SNMPv3/VACM access control
> might be acceptable. Of course, as Juergen pointed out, it might be
> possible to use VACM with an authenticated SNMPv1/v2c message.

With a new security model.

> SNMPv3 is a fairly expensive upgrade from SNMPv1 for an agent and the

But that point seems to be moot, since it's already out there for the agents.

> surrounding security infrastructure. But leveraging an SSH or SSL
> approach, which could be applied not only to SNMP but also to CLI
> and/or web-based interfaces might justify the incremental costs to
> slightly modify the legacy SNMPv1 agents.

Could be.  What worries me, though, is that I still haven't seen a convincing
argument that the management platform vendors would be any more
motivated to get their act together for this than for SNMPv3.

> -- demand for VACM
>
> I haven't found much demand for VACM-style access control from
> operators so far.
>
> I think this is because this access control is not consistent with the
> access control/authorization mechanisms used for other management
> interfaces, much as USM is not consistent with the authentication
> mechanisms for other management interfaces. I think we need to solve
> the authentication-consistency problem first, then we can try to solve
> the authorization-consistency issue.

The way this WG has been chartered leaves us little choice here.

> I believe the authorization-consistency issue will require that other
> management interfaces make their data objects addressable in a
> standard manner. The netconf data modeling may provide mechanisms for
> addressing data points hierarchically, and then a VACM-style access
> control could be applied to the data for netconf. Hopefully, netconf
> will lead the way for standardizing scripting, ala CLI scripting, and
> that might lead to some standardization of an addressing mechanism for
> CLI parameters. Web-based management data points might also become
> addressable via XML. If we can standardize addressability of CLI and
> web-based data points, then VACM-style access control could be applied
> to those management interfaces. But before we get there, we need to
> get user-authentication consistent across interfaces.

This is an operational problem that we're addressing as a protocol problem.
Let's hope it works.

> I think it possible that operators will ask us to develop an
> authorization mechanism that is more consistent with existing CLI
> access control mechanisms, which may or may not be consistent with the

The access control for the CLIs I've used (in the distant past) had very
little in common with each other.  Let's hope your optimism is justified.

> VACM approach. VACM might be able to be deployed in a manner that
> would make it consistent with existing CLI access control, but so far
> we haven't told the operators how this can be done with VACM, probably
> because CLI access control hasn't been consistent across vendors (or
> even within vendors' product lines in many cases).
...

Agreed.

Randy

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

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 27 Jan 2005 17:49:47 +0100

<inline>
Tom Petch
----- Original Message -----
From: "Randy Presuhn" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 27, 2005 1:48 AM
Subject: Re: [Isms] Evaluation status [and more]
> have much of a point until teamed up with an access control model of some
kind.

but that access control model can be much simpler.  Outside of SNMP, the most
complex I typically find is
 - no access
 - read access to everyday things
 - read access to almost everything and write access to most configuration
details
 - read access to everything and write access to almost everything (eg software
reload)

Using SNMP (v1) then this often maps into a choice of community name perhaps
coupled with a check on the source IP address which, if passed, gives me one of
these
levels of access.

This is so simple that I would not normally dignify it with the name of an
access control model, but it does the job; or would if the authentication -
community name, source IP address - were strong enough to counter modern
attackers.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 27 Jan 2005 11:03:24 -0800

Hi -

> From: "Tom Petch" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Thursday, January 27, 2005 8:49 AM

...
>  - read access to everything and write access to almost everything (eg software

This begs the question of how one identifies which things are "everyday things",
which things are "configuration details", and which bits are sensitive like
"software reload".  As other postings in this thread have indicated, SNMP's
naming architecture quickly drives you to something like VACM.  But the real
point here is that you've just described an access control model.  Without
real authentication, the access control model is pretty useless, and with an
access control model, the only value of authentication would be an audit trail,
and we don't (currently) do that.

> community name, source IP address - were strong enough to counter modern

And pigs could easily fly if they had wings and were lighter and were more
aerodynamic.  :-)  Seriously, one could define a new protocol that contained
SNMPv1 PDUs, and new  security model to map its security levels and user
identification mechanism into access control groups for VACM or some other
security model, but I really don't see how that would bring us any closer to the
WG's goal of integrating SNMPv3 with non-SNMP security infrastructure.

Randy

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 28 Jan 2005 12:19:15 +0100

I expect I am not making myself clear.  I am agreeing with David that SNMPv1/v2c
with better authentication is enough.  I am disagreeing with the idea that
because of VACM, reusing parts of SNMPv1/v2c does not save anything.

Whether using SNMP or CLI, I have never had, and have never missed, what SNMPv3
VACM has to offer, all that putting objects into trees so that I
can offer fine grained authorisation as part of network management.  (System
management is different).  Rather, the manufacturer of the router or switch or
hub has set up two or three or four proprietary categories of authorisation and
has pre-assigned, immutably, all functions into a category for me; and that is
adequate.

All I then need is authentication that the sender of the SNMP message has low
or medium or high security; this could be implicit in the authentication,
eg determined by key length.  Authentication matters, and needs to be strong,
but authorisation can be a simple ternary or binay model for many needs.

Tom Petch

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 28 Jan 2005 08:42:15 -0500

Hi,

SNMPv1/v2c with message integrity checking and confidentiality,
yielding better authentication is enough in environments that don't
require VACM; other environments may want the full-blown features of
SNMPv3/VACM. Lower layers may be able to provide the
integrity/confidentiality security features for SNMPv1/v2c messages,
and also for SNMPv3 messages.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Friday, January 28, 2005 6:19 AM
> To: Randy Presuhn; [email-masked]
> > > > define a new security model to make use of it, since 
> authentication
> doesn't
> > > > have much of a point until teamed up with an access 
> control model of some
> > > > kind.
> > >
> > > but that access control model can be much simpler.  
> Outside of SNMP, the
> most
> > >  - read access to everything and write access to almost 
> everything (eg
> software
> > > reload)
> >
> > This begs the question of how one identifies which things 
> are "everyday
> things",
> > access control model, the only value of authentication 
> would be an audit
> trail,
> > > coupled with a check on the source IP address which, if 
> passed, gives me one
> of
> > > these
> > > levels of access.
> > >
> > security model, but I really don't see how that would bring 
> us any closer to
> the

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 28 Jan 2005 12:06:37 -0800

Hi -

> Sent: Friday, January 28, 2005 3:19 AM

> because of VACM, reusing parts of SNMPv1/v2c does not save anything.

SNMPv2c and SNMPv3 have the same PDU format, and only differ in
the "wrapper".  The wrapper is where authentication information is carried
in these two protocols.  Fixing SNMPv2c authentication so that it actually
provides some security results in a different protocol, modifying the fields
where SNMPv2c and SNMPv3 differ.

The issue is not VACM, it's *ANY* access control model.
Without authentication, access control doesn't have what it needs to
make a decision.  Providing authentication without access control
would make an audit trail possible, but would provide no protection.

> VACM has to offer, all that putting objects into trees so that I

This is the only way we have of uniquely identifying information in SNMP.

> can offer fine grained authorisation as part of network management.  (System

There's nothing that requires you to use the fine-grained capability if you don't
need it.

> has pre-assigned, immutably, all functions into a category for me; and that is

And this could be done with VACM (StorageType=permanent) and pre-defined
groups by manufacturers, if they thought customers would buy it.  Consider
RFC 3415 appendix A.1 as a case study.

...

If I understand you correctly, you're making a couple of claims:

    1) the number of groups in most VACM configurations would be
        two or three.  (For a lot of equipment, I believe this to be true.)

    2) the decision about which bits of management information should
        be accessible to which of these groups does not need to be
        under control of the security administrator.

    3) equipment manufacturers will decide which groups get which access,
        and it would be acceptible if this could be changed only by a
        firmware/software upgrade

Did I get this much right?
If so, do you think a standard policy for these could be formulated as an
addendum to RFC 3415 appendix A.1?

Randy

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 28 Jan 2005 16:09:21 -0500

> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> 
I believe this is fairly accurate as a representation of what exists.
And I think we coul dhelp the SNMP community migrate from communities
to VACM much more than we have by defining incremental migration
paths.

We could do a service to operators by defining some standard access
control templates for VACM groups, comparable to public (r-o most),
private (r-w-most), and super-user (r-w-all).  This would help admins
accustomed to the traditional SNMPv1 communities to migrate to VACM
access control. Then admins could expand the group assignments from
that point if desired. I would consider adding a new security-admin
(r-w security mibs, such as VACM and USM and RADIUS) as well.

I think it would help admins if we discussed how applications can
serve as SNMPv3 USM users, for all their users. Some applications
already provide user-level access control. I don't like this as much
as agent-access-control, but it is easier to configure USM with a few
applications than with larger number of users, while ISMS tries to
improve ease-of-use. On a side note, Spectrum used to provide
something like nine levels of user access control, and now only
provide three because customers never used the extra six levels.

In SNMPv1, the immutable assignments were made to communities, but I'm
not sure whether contexts, views or groups are the right answer in
SNMPv3. Contexts are the immutable entities, so I think contexts might
be the right answer. I think we could help the vendors provide default
assignment of mib modules to public/private/root contexts by providing
a list of IETF mib modules, and recommend which context they should be
associated with.

David Harrington
[email-masked]

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 28 Jan 2005 14:24:46 -0800 (PST)

HI,

Interesting...
Lets say there are three "roles" or "capabilities",
which would correspond to VACM groups. Given
these, the standards track documents containing MIB modules
could indicate which objects and notifications should
be available for access type for each role. Given this
info in RFCs, it would be a mechanical process to
create entries in the view, and access tables.
That is, entries in table vacmViewTreeFamilyTable,
and table vacmAccessTable.

Entries would be created in tables usmUserTable and
vacmSecurityToGroupTable when support for a new a user
is added. And entries would be created in tables
snmpCommunityTable and vacmSecurityToGroupTable
when support for a new community string is added.

> a list of IETF mib modules, and recommend which context they should be

Regards,
/david t. perkins

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 28 Jan 2005 19:00:43 -0500

Yes, and if you can parse the security considerabtions boilerplate to
find the objects in each category, that info may already be broken out
to a degree. Not well, but to a degree.

dbh 

> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Friday, January 28, 2005 5:25 PM
> To: David B Harrington
> Cc: [email-masked]
> > >         and it would be acceptible if this could be 
> changed only by
> > a

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 31 Jan 2005 13:08:55 +0100

Thank you to you all for fleshing out my half-formed ideas:-)

Yes I am suggesting public/private/root and that manufacturers would supply a
default assignment; I hadn't thought of it being built into firmware but I
expect that would satisfy most needs .

I shy away from VACM because I don't understand it; I know of the tables
mentioned but unless and until I actually configure them, I doubt if I will
remember which is what and so have to go away and look up their role.  If David
(Perkins) says this is the way to do it, I take that on trust.  And I suspect
that VACM is a lot more complexity to implement, in the general case, which may
be a factor in the lack of implementations of SNMPv3.  So part of me wants to
dispense with VACM or make it so simple (eg with three groups and nothing more,
MAX-ACCESS of read-only?) that the cost would be negligible.

Despite this, I suspect that VACM groups are the better fit.  I am hoping
contexts will solve
the multi-function box problem, of a chassis with multiple blades, routers,
switches, hubs etc each wanting its own distinct 'MIB-II'.  So loading the
concept of
context with security could compromise this (again, a half formed idea).

And yes, I do see it as an addendum to RFC 3415, perhap RFC 3414. I think we
need a(nother) starter subset.

My last half-formed idea for the moment (which I realise has a lot of baggage
around it).  SNMPv1 took a time to catch on.  For me, it was a capable set of
building bricks that needed a lot of effort to be usable and it took off when a
manufacturer produced something more like a ready to use structure (HP
OpenView).  I see in SNMPv3 a capable set of building bricks and have been
waiting for a manufacturer to produce something more like a ready to use
structure (eg a starter set of VACM and USM tables) - I am still waiting.
Perhaps a move from the standards side - ie us - to something simpler (while not
losing sight of our role to integrate security with existing systems) might get
that response from a manufacturer.

Tom Petch