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

From: "Nelson, David" <[email-masked]>
Date: Tue, 11 Jan 2005 15:11:29 -0500

Uri Blumenthal writes...

> I want to poll the group: do you agree that in order 
> to cleanly integrate with any of the existing infrastructures,
> SNMP needs to define and embrace the concept of a session.
> If there's agreement - I'll finish my write-up and submit it.

I agree.

The notion of session might be accomplished via use of an existing secure session context (e.g. TLS session, IPSec SA, etc.) or it could simply be defined using the current SNMPv3 privacy mechanism, based on the lifetime of the "session keys".  We would need to adopt an appropriate authenticated key management system (e.g. Kerberos, etc.) to meet this requirement.

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

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 11 Jan 2005 16:00:08 -0500

Hi,

I would phrase the requirement slightly differently.
I do not believe that "in order to cleanly integrate with any of the
existing infrastructures, SNMP needs to define and embrace the concept
of a session.", but rather if SNMP embraced the concept of a session,
it would have a much much larger selection of existing infrastructures
with which to integrate.

If we adopt a third-party-authenticated session, we still need to have
a fallback to a UDP-based trasnport and limited local authentication
for troubleshooting a broken network.

I think the benefits of a session approach are numerous:
If we adopt a secured-transport session, we may not have to provide
message authentication, integrity, and timeliness in the SNMP engine.
If we adopt a secured-transport session, we might send multiple SNMP
messages within the same session, to minimize the overhead.
If we adopt a secured-transport session, we might make this
host-to-host, which is similar to the way many operators
"authenticate" SNMPv1 messages. 
If we adopt a secured-transport session with host-level
authentication, we might make user-authentication part of the
authorization stage, so we don't have to pass the security principal
from the transport layer to the application layer.
If we adopt a secured-transport session, we might be able to transport
the simpler SNMPv1 or SNMPv2c message formats securely.

If we adopt a stream-based transport session, we might send much
larger messages, improving SNMP's efficiency for table retrieval.
If we adopt a stream-based transport session, that would make SNMP
much more consistent with other management interfaces, like CLI/SSH
and NETCONF.
If we adopt a stream-based transport session, we could more easily
utilize an XML-based data description approach, and move away from
ASN.1.

I, for one, would like to see us adopt a session-based approach to
supplement the UDP-based approach needed for troubleshooting broken
networks. My preference would be to utilize sessions already provided
by lower-layer protocols, so we can simplify SNMPv3.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Tuesday, January 11, 2005 3:11 PM
> To: [email-masked]
> Subject: RE: [Isms] Evaluation status [and more]
> 
> Uri Blumenthal writes...
> 
> The notion of session might be accomplished via use of an 
> existing secure session context (e.g. TLS session, IPSec SA, 
> etc.) or it could simply be defined using the current SNMPv3 
> privacy mechanism, based on the lifetime of the "session 
> keys".  We would need to adopt an appropriate authenticated 
> key management system (e.g. Kerberos, etc.) to meet this
requirement.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 Jan 2005 14:18:57 -0800

Hi -

> From: "David B Harrington" <[email-masked]>
> To: "'Nelson, David'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, January 11, 2005 1:00 PM
...
> by lower-layer protocols, so we can simplify SNMPv3.
...

At an implementation level, an SNMP Engine that supports USM
already needs something very much like a session internally if
it's going to be sending Informs or supporting a command generator
application.  It needs to remember the SnmpEngineID, boots, and
time offsets of its current set of communication partners, and needs to
employ some kind of caching strategy to manage memory as the
membership of this set changes over time.  Making these explicit
in protocol and architecture could potentially make things easier
to understand.  From my perspective, layering user sessions atop
these engine-to-engine sessions is a reasonable next step.

Randy

---

From: "Wayne Kading" <[email-masked]>
Date: Tue, 25 Jan 2005 18:09:51 -0600

The following statement made by David on SNMP v1/v2c security prompted this
comment.  Due to legacy security concerns where SNMP v1/v2c/v3 equipment
coexists, it appears that SNMP v1/v2c security should be addressed in the
evaluation criteria and related proposals if it isn't already.  I would also
be interested to see what importance is assigned to this criteria as it is a
concern in many large environments.

Wayne

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David B Harrington
Sent: Tuesday, January 11, 2005 3:00 PM
To: 'Nelson, David'; [email-masked]
Subject: RE: [Isms] Evaluation status [and more]

.
.
.
.

David Harrington
[email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 25 Jan 2005 19:57:23 -0800

Hi -

> From: "Wayne Kading" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, January 25, 2005 4:09 PM

...

I'd say it's too late for this, since none of the proposals submitted
to the WG try to do this.  Furthermore, it's hard to see how any sort
of encapsulation could help legacy equipment.  If one needs to
update the gear to support the encapsulation, one may as well
do it right and go to SNMPv3 in order to get the benefits of access
control.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Jan 2005 09:10:13 +0100

On Tue, Jan 25, 2005 at 07:57:23PM -0800, Randy Presuhn wrote:
 
> to the WG try to do this.  

Some proposals may allow for this while other do not, even though
this is not explicitely stated. I guess not all evaluation criteria
have been addressed by the various proposals (which is no surprise
since the criteria even today are not known). The key thing here is
to try to identify what addresses the requirements of which segment
of the overall SNMP market. (And I know that this is really difficult
with the limited input we get.)

> Furthermore, it's hard to see how any sort of encapsulation could 
> help legacy equipment.  If one needs to update the gear to support 
> the encapsulation, one may as well do it right and go to SNMPv3 in 
> order to get the benefits of access control.

I fail to understand the access control argument. You can do VACM 
access control with SNMPv1/SNMPv2c today as far as I understand 
things. Please correct me if I am wrong.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Jan 2005 09:11:55 +0100

On Tue, Jan 25, 2005 at 06:09:51PM -0600, Wayne Kading wrote:

> Due to legacy security concerns where SNMP v1/v2c/v3 equipment

Can you explain what the potential market impact of being able to ship 
legacy SNMP over a secure transport actually is? I know this is hard to
judge but actually the most critical question to ask when evaluating
the proposals.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 26 Jan 2005 13:05:29 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, January 26, 2005 12:10 AM
> Subject: Re: [Isms] Evaluation status [and more]
...
...

RFC 2576 section 5.2.1 requires requests coming in this way to be
handled as NoAuthNoPriv.  So yes, one can subject these to access
control, but it's meaningful only in that anything other than "public"
would still have to come in through SNMPv3.  If one wanted these
encapsulations to be handled differently, that is, recognizing them
as authenticated, then one would need to define a new security model
for the encapsulation, etc., which brings me back to my main point:
it doesn't help legacy equipment, since one would need to install new
software.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 26 Jan 2005 23:58:05 +0100

> it doesn't help legacy equipment, since one would need to install new

I think the argument was more that if you use a secure transport, you
can probably get rid of some of the SNMPv3/USM header overhead. Needs
some byte counting to see whether this is worth the effort.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 26 Jan 2005 15:30:01 -0800

Hi -

> Sent: Wednesday, January 26, 2005 2:58 PM
...
...

Yup.  After all, bandwidth is so precious we wouldn't want to waste any
bits.  That's why we use BER rather than XML.  ;-)  Seriously, though,
Wayne's point was about "legacy security concerns where SNMP
v1/v2c/v3 equipment coexists".  I understood "legacy" to refer to
existing hardware/software that, for whatever reason, has not been
upgraded to current standards.

Randy

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 26 Jan 2005 19:04:34 -0500

Hi,

If the argument you refer to was the ue of SNMPv1 messages over a
secure transport, my intent was not to say only that we could reduce
header overhead in the SNMPv3 message. 

My comment was that SNMPv1/v2c format messages might be able to be
used if a secure transport provided the message confidentiality and
integrity checking. 

If transport-independent user authentication is desired, it might be
able to be provided via a secure-community model, ala SNMPv2a.

Using the SNMPv1/v2c message format would of course preclude some of
the features of SNMPv3, like proxy. To dredge up history a bit, I
think such usage might be akin to what SNMPv2u or SNMPv2a promised,
and would lose some of the additional features from what snnmpv2*
promised. For those who want the additional features, SNMPv3 format
messages could be used over the secure transport ( and that the
secured-transport security model might reduce the processing overhead
compared to USM).

David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Wednesday, January 26, 2005 5:58 PM
> To: Randy Presuhn
> Cc: [email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 26 Jan 2005 19:15:39 -0500

Hi,

Some comments:

-- RFC2576 requirements

Note that RFC2576 is obsolete; it has been replaced by RFC3584. The
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.

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

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

SNMPv3 is a fairly expensive upgrade from SNMPv1 for an agent and the
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.

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

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.

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

My $.02
David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Wednesday, January 26, 2005 4:05 PM
> To: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jan 2005 01:31:08 +0100

> secured-transport security model might reduce the processing overhead

The question is where you want to draw the line this time. 

There are a number of things in the SNMPv3 header that are in 
principle very good general enhancements of SNMPv1/SNMPv2c 
(msgMaxSize and scoped PDUs come to my mind). On the other 
hand, the many people still using SNMPv1/SNMPv2c seem to be 
happy enough without these features - I can't remember having
ever talked to an operator who complained about message size 
problems or who have a real problem to use a public@something
community string where needed.

But I think we are slipping out of the charter here which I
think says the SNMPv3 message header is something we are not
expected to touch or discuss. So if my reading of the charter
is right, the only thing to consider by this WG is the 
information carried in the USM header.

/js

---

From: pmrn <[email-masked]>
Date: Wed, 26 Jan 2005 19:54:35 -0500

Even though I don't work on the WG, I look at the discussion board.

Dave is absolutely correct. Today, default password can be changed to 
any compatible password. As a matter of we urge users to do so for 
security reasons. I was under the impression that the Proxy module 
SNMPv3 is backward compatibility. VACM in combined with the Proxy Agent 
should be able to provide backward compatibility and allow SNMPv3 to 
interoperate with v1, v2, etc.

Pall Ramanathan
Amalan Networks

>> it doesn't help legacy equipment, since one would need to install
Pall Ramanathan
Work: 678-9359670
Mobile: 678-576-7105

www.amalannetworks.com

Learn like you will live for ever and Live like you will die 
tomorrow-Gandhi
_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jan 2005 02:18:18 +0100

> I haven't found much demand for VACM-style access control from

No surprise. 

I would not use an access control system on my hard disk which operates 
on the block address level while everything I am doing on my hard disk
is expressed on the file abstraction level.

Operators worry about logical entities such as interfaces not about OIDs.
VACM simply does not help (except for defining generic read-only access
to protect yourself against potentially nasty writable MIB objects ;-).

To be fair, the real root of the problem is the naming system that
forced the design of VACM. So in the light of this discussion, whatever 
netconf may come up with is hopefully incompatible with VACM.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 26 Jan 2005 21:04:07 -0500

Hi,

I disagree with your pessimism, but I agree with the issue with the
naming system, and the analogy of block-based versus file-based
abstraction. 

That's why I mentioned a VACM-**style** access control system, rather
than a VACM-compatible system. I think VACM, adapted to a different
naming system (and different verb names), could be viable as an access
control model for other management interfaces, if the addressing
models for those other management interfaces are hierarchical in
nature.

If netconf defines an XML-based hierarchical data structure, and the
VACM ASI is modified to work with a XML-based hierarchical addressing
mechanism, and a verb system comparable to the VACM verb system
(get-config, etc.), I think a VACM (hierarchical view-based) approach
would be reasonable.

I look at CLI interfaces that have "subsystems" of commands and verbs
that are consistent across subsystems (e.g., set and show), that
correspond roughly to SNMP verbs (set, get), and I think an adapted
VACM approach very reasonable.  

David Harrington
[email-masked]

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Wednesday, January 26, 2005 8:18 PM
> To: David B Harrington
> Cc: 'Randy Presuhn'; [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 26 Jan 2005 19:18:26 -0800

Hi -

> From: "pmrn" <[email-masked]>
> To: <[email-masked]>
> Cc: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, January 26, 2005 4:54 PM
...
...

That's not how SNMP proxy works.  See http://www.ietf.org/rfc/rfc3584.txt
for details.  The VACM configuration at the proxy is not applied to
forwarded requests and responses.  One could argue about whether this
is a bug or a feature, but this was the approach taken for reasons of
compatibility with earlier approaches to SNMP proxy.  One would need to
define a new kind of proxy if one wanted to do the access control at the proxy
as well as at the managed device.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jan 2005 08:34:52 +0100

On Wed, Jan 26, 2005 at 09:04:07PM -0500, David B Harrington wrote:

> than a VACM-compatible system.

Sorry for misreading vacm-style as vacm-compatible.

/js

---

From: "Wayne Kading" <[email-masked]>
Date: Mon, 31 Jan 2005 12:46:08 -0600

After reading the recent posts to this list and reviewing Wes' survey dated
2004-08-11, the compatibility concern with legacy SNMP which I raised below
may not be as important as originally thought to be.  Even though 62+% of
users are still on SMNPv1/SMNPv2 per Wes' survey, there may be more interest
in moving to SNMPv3 if a firmware upgrade of the client is required as Randy
suggested.  I also noticed that Wes' survey indicates on p. 4 that 86% of
the users said they would use SNMPv3 if it would support one or more of
their existing authentication methods.

Wayne

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2005 2:12 AM
To: Wayne Kading
Cc: [email-masked]
Subject: Re: [Isms] Evaluation status [and more]

/js

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 31 Jan 2005 13:40:41 -0800

>>>>> On Mon, 31 Jan 2005 12:46:08 -0600, "Wayne Kading" <[email-masked]> said:

Wayne> I also noticed that Wes' survey indicates on p. 4 that 86% of
Wayne> the users said they would use SNMPv3 if it would support one or
Wayne> more of their existing authentication methods.

Some of the comments actually said similar things.  IE, the reason
they hadn't moved to V3 was it was going to be a pain.  If ISMS
results improve on this then they'll be more likely to switch.  The
survey results very clearly spelled that out, IMHO.

-- 
Wes Hardaker
Sparta