Subject: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 21:48:51 +0100

ISMS #8: support of v1/v2c transport-authn for ACM
Status: open

David Harrington wrote:

    whether to try to support v1/v2c transport-authn for ACM

I believe this concerns the question whether this WG should consider
how SNMPv1/SNMPv2c, that is the community based security model, can
utilize a secure transport.

Q8.1: Is this question in scope of the WG charter?

Q8.2: If yes, what needs to be done to make this happen? Is there a
      way to make existing code do something it was not expected to
      do?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jan 2008 17:07:17 -0500

Hi,

Bert Wijnen wrote:
"  Now I do see that in sect 2.3 you explain/state that the Transport
  Security Model cannot be used with SNMPv1 and SNMPv2c. 
  I wonder if this is what the operator/user community
wants/accepts??"

If we deliver something that does not meet what operators want, and
they refuse to use our ISMS standard (as well as our USM standard),
have we wasted another two and a half years?

To standardize the use of SNMPv1/v2c over secure transports means we
would need to modify some existing elements of procedure in RFC3584
and RFC3412 (I think those are the only two). The changes could be
conditional changes based on the existence of, or contents of,
tmStateReference so the elements of procedure would be backwards
compatible with existing implementations. 

Basically, a secure transport model can specify which security model
should be used to determine securityName, but in the absence of a
secure transport model determination, the MPM decides which security
model should be used. The work would need to specify something like
"to support this functionality, the elements of procedure of RFC3412
are amended by the following change: ...."

I think the result would be more in keeping with what operators want.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, January 23, 2008 3:49 PM
> To: [email-masked]
> Subject: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Jan 2008 17:22:13 -0500

> I think the result would be more in keeping with what operators want.

Hrm.  Wouldn't this have the effect that if SNMPv3 is used with USM over 
SSH case, it is USM that gets ignored rather than SSH?  I don't think we 
want that.

OTOH, I'm inclined to agree that what you describe is likely to result in 
reasonable behavior for SNMPv1/v2c.

I think to make this work, we need to distinguish between MPM's that 
actually have the ability to negotiate a security model from those that do 
not.

Having just reread the charter, I'm unclear on whether this is in scope. 
The language "The new security model must not modify any other aspects of 
SNMPv3 protocol as defined in STD 62" seems intended to limit what we can 
do, but I'm not sure to what extent.  I do agree that making this work is 
worthwhile, and probably requires changes to the EoP.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jan 2008 17:55:07 -0500

inline 

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Wednesday, January 23, 2008 5:22 PM
> To: David Harrington; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for
ACM

> actually have the ability to negotiate a security model from 

All MPMs determine which security model gets called, according to the
architecture. How the determination is made is message-model specific.
The three existing messaging models make the determination based on
fields in the message header (i.e., the community field of v1/v2c, or
the msgSecurityModel field in the SNMPv3 header).

My suggestion is to **conditionally** modify the determination
algorithm so that **if** a secure transport model is used, the secure
transport model chooses (or requests) which security model the
messaging model should call. If the transport model (such as the UDP
transport "model") does not make such a determination, then the
decision reverts to the existing MPM determination algorithm.

> worthwhile, and probably requires changes to the EoP.

I expect that the change required would be of the form:
in RFC3412 section 7.2, insert step 3a) "If tmStateReference exists
and specifies a security model in the tmSecurityModel field, then set
msgSecurityModel to tmSecurityModel." 

I would have preferred to see existing text that said
"set securityModel, to msgSecurityModel", and then to add a step that
said "If If tmStateReference exists and specifies a security model in
the tmSecurityModel field, then set securityModel to tmSecurityModel."
But we never actually specific the assignment of the msgSecurityModel
value to the securityModel parameter of processIncomingMessage().

dbh

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Jan 2008 19:24:36 -0500

> decision reverts to the existing MPM determination algorithm.

Right, I got that.  But one effect of that is that if you use SSH, then SSH 
is always going to say "use TSM", and the msgSecurityModel field in the 
SNMPv3 header is going to be ignored (well, changed to TSM, but with the 
same effect).  Which means you then can't actually do USM-over-SSH.

I'd just as soon not have SNMPv3 be affected by whatever we decide to do to 
make v1/v2c work.

-- Jeff

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Jan 2008 17:21:09 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, January 23, 2008 12:48 PM

I'd say no

>       way to make existing code do something it was not expected to

Even if it could be in scope, I think we need a clear answer *why*
one would want to do such a thing.  What would be the point of
building a SNMPv1 or SNMPv2c implementation over SSH?
It still wouldn't support 64-bit counters, GetBulk, Informs, or
extended error codes.   Seems like it would be inviting folks
to waste their time.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Jan 2008 17:24:16 -0800

Hi  -

> From: "Randy Presuhn" <[email-masked]>
...
> extended error codes.   Seems like it would be inviting folks
...

("It" being SNMPv1.)

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jan 2008 20:54:51 +0100

> I think the result would be more in keeping with what operators want.

Speaking as technical contributor...

Can you provide a reason why SNMPv2c'/SSH is operationally more
desirable than SNMPv3/TSM/SSH? 

I fail to see the benefit because both SNMPv3/TSM/SSH and the new
SNMPv2c'/SSH will essentially do the same, namely pull the
securityName out of the SSH layer.

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 24 Jan 2008 15:21:16 -0500

Juergen Schoenwaelder writes...
 
> Can you provide a reason why SNMPv2c/SSH is operationally more
> I fail to see the benefit because both SNMPv3/TSM/SSH and the
> new SNMPv2c/SSH will essentially do the same, namely pull the

I don't see the benefit either.  The SNMP architecture is modular.  AFAICT,
SNMP implementations are generally not so modular.  Assuming that a new
software product release would be needed (no plug and play), why would the
engineering/development/deployment effort to enhance SNMPv2c product be
desirable, if the same effort applied to SNMPv3 product produced the same
security benefits to the operator?

It might be academically interesting to specify how to implement
SNMPv2c/SSH, but why would someone choose it over SNMPv3/TSM/SSH?

---

From: "tom.petch" <[email-masked]>
Date: Fri, 25 Jan 2008 13:56:50 +0100

----- Original Message -----
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 24, 2008 9:21 PM
Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM

> SNMPv2c/SSH, but why would someone choose it over SNMPv3/TSM/SSH?

SNMPv3 has a mandatory-to-implement USM, SNMPv2c does not; should save on the
development effort.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Jan 2008 17:43:40 +0100

> SNMPv3 has a mandatory-to-implement USM, SNMPv2c does not; should save on the

SNMPv2c is experimental in the first place. Still it makes operators
happy. So you can do SNMPv3/TSM/SSH and make operators happy without
doing USM. You are not going to be SNMPv3 compliant - but does the
operator care? Are we seriously considering to hack around in the
otherwise religiously followed SNMP architecture just to get around
the USM requirement for SNMPv3?

/js (as technical contributor)

---

From: "David Harrington" <[email-masked]>
Date: Fri, 25 Jan 2008 11:53:27 -0500

> From: David B. Nelson [mailto:[email-masked]] 
> Sent: Thursday, January 24, 2008 3:21 PM
> To: [email-masked]
ACM
> security benefits to the operator?

Implmentation cost of developing what? adding SSH to the SNMPv3 engine
of an agent vs the cost of adding SSH support to the SNMPv2c engine of
an agent? Yes, the costs might be similar for that development effort.

How about the costs of converting an SNMPv1/v2c NMS with full
graphical interfaces to being an NMS with full graphical support for
SNMPv3? Let's see what the costs of that development might be:
1) changing the database and GUIs to use contextEngineIDs rather than
IP addresses to identify a node,
2) changing the database and GUIs that support entering a
communityName to entering a securityEngineID plaus securityName, and
then mapping those to the SSH equivalents,
3) changing any support for communities as "naming scope" that can
encompass multiple devices to support contextNames that are local to a
specific contextEngineID,
 etc. etc. etc.

SNMPv3 adds a whole lot of changes in the conceptualization of the
system beyond what SNMPv2c added versus SNMPv1.

It would be comparatively MUCH simpler to add SSH support to an
existing SNMPv1/v2c application than  adding SSH PLUS SNMPv3 support
to the same application. And of course, it would be much easier to
train existing NOC personnel in how to use SSH added to already known
SNMPv1/v2c applications, than to train them in all the concepts of
SNMPv3 plus how to use SSH for securing the transport.

There is a massive difference in costs between making NMS applications
that already support SNMPv1/v2c capable of using SSH versus making it
a requirement to upgrade to SNMPv3 to get SSH support. And many
application vendors have already made it quite clear they are not
convinced the demand is there for them to invest in such massive
upgrades to their applications to support SNMPv3, and most operators
have already made it clear they don't intend to demand this of
application vendors.

So where are the benefits? In the reduced costs of migrating a system,
versus the cost of migrating an agent.

Does this mean we should just toss SNMPv3 and the modular
architecture? No, conceptually it means that vendors and operators can
migrate portions of the (architectural) system as needed. They can
still use SNMPv1 and SNMPv2c messags, but with an SSH/TCP transport
and a TSM-like security model to supplement/replace the UDP transport
model and the community-based security models. This gives them good
authentication and encrypted messages based on existing security
systems, which many operators and NMS vendors agree they want now.

Since an SSH approach provides real authentication, compared to
communties, they can utilize VACM (without having to support USM) when
they decide that functionality is really needed.

If they keep using SNMPv1/v2c messages, they can continue to use
community as a "naming scope" while migrating away from community as
an authenticator. When they want contextEngineID/contextEngineNmae
naming scopes, they can migrate to SNMPv3 messages to get that.

Forcing full SNMPv3 in order to get SSH secure transport makes it hard
to convince people they should migrate their SNMP systems.

David Harrington
[email-masked]
[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Fri, 25 Jan 2008 12:08:55 -0500

> Sent: Friday, January 25, 2008 11:44 AM
> To: tom.petch
> Cc: [email-masked]
> Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for
ACM

> operator care? 

No they don't. So we can publish something as a standard that we know
nobody will actually implement because it makes no sense, but at least
we can sleep soundly at night knowing the standard maintained the
sacred modularity of RFC3411, and knowing that implementers are smart
enough to find proprietary hacks to the standard to make it work the
way operators want it to.

Do we have our priorities in order here?

> Are we seriously considering to hack around in the

"religiously followed?" - we have redesigned the ASIs! We have added
the equivalent of void pointers so we can pass model-dependent
structures from one subsystem to other subsystems! In RFC3411/3412,
the security model was not allowed to know anything about the
transport, including which transport was being used! "religiously
followed?"

The fact that we have added tmStateReference to the ASIs is what makes
it possible to support SNMPv1/v2c over SSH in a manner that is at as
close to the original architectural modularity as the changes made for
tmStateReference, and adding support for SNMPv1/v2c over SSH would
make operators happy. 

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Jan 2008 18:39:23 +0100

> IP addresses to identify a node,

Frankly, almost nobody does identify agents using contextEngineIDs as
far as I can tell. So you don't have to do this change to move from
SNMPv2c to SNMPv3.

> then mapping those to the SSH equivalents,

For our hacked NET-SNMP code, using SNMPv3/TSM/SSH is almost identical
to using SNMPv2c as long as you use the default context. Instead of a
community name and a transport address, you provide an SSH user name
and a transport address. And even better, if you do not provide an SSH
user name, we use the user's account name - so it is even a parameter
less!

> specific contextEngineID,

Since there is no standard way to encode a context name in a community
string, this is grey area on the management application side anyway.

>  etc. etc. etc.

???

> There is a massive difference in costs between making NMS
> applications that already support SNMPv1/v2c capable of using SSH
> versus making it a requirement to upgrade to SNMPv3 to get SSH
> support.

I don't really believe this. Perhaps my notion of massive is different
from others.

If the argument is that SNMPv3 is too complex to implement for
management applications, then this discussion probably needs to be
raised in some other forum of the IETF.

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 25 Jan 2008 13:06:06 -0500

I thought the charter of ISMS was to address a problem that could be
characterized as: "SNMPv3 is not widely deployed because the lack of
centralized authentication and key management is an impediment to ease of
use."

The solution was to add a new Security Model to SNMPv3, that leveraged
existing authentication infrastructure.

Now we are hearing that the solution ought to be to invent SNMPv2d?
(Assuming that the "d" variant of SNMPv2 has not been previously defined.)
How did we get to that point?

---

From: "Bert Wijnen" <[email-masked]>
Date: Sat, 26 Jan 2008 00:33:58 +0100

W.r.t.
> string, this is grey area on the management application side anyway.

Mmm... does not the SNMP-COMMUNITY-MIB in RFC3584 cater for that?

> I don't really believe this. Perhaps my notion of massive is different

So why was it that HP did not support SNMPv3 in their NMS?
I do not know if this is still the case or not.

I do know that most agents were/are multi-lingual (SNMPv1,v2c,v3) but
there are not that many NMSes that are SNMPv3 capable as far as I
know. Now... I must admit that I have not kept track of that too
closely in the last few years.

> raised in some other forum of the IETF.

Too complex or not is not the major question.
The major question is/are
- does it actually get implemented?
- does it get deployed?

Bert

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Jan 2008 16:54:31 -0800

Hi -

Just a procedural question -

How would having a normative dependency on an
experimental (SNMPvc) RFC affect this work
process-wise?

Or is the real sub-text of this discussion that SNMPv3
should be withdrawn from the standards track?

Randy

---

From: "David Harrington" <[email-masked]>
Date: Sat, 26 Jan 2008 00:51:22 -0500

Hi,

I don't see that there would be any dependency on SNMPv2c, or on
SNMPv1, or on SNMPv3.

The ISMS documents that describe passing the new tmStateReference
parameter through the ASIs would discuss that when a tmStateReference
is passed, a secure transport model uses tmStateReference to provide
the equivalent of the msgSecurityParameters block for any version of
SNMP message. We already have the transport model provide the
securityName and securityLevel; we just don't provide the
securityModel in tmStateReference.

USM requires msgSecurityParameters to be passed in the SNMPv3 message
header; TSM requires the same model-independent information be passed
in tmStateReference instead. The change needed is to have the process
for selecting the security model recognize the potential existence of
the tmStateReference, and use its contents in the decision, just as
the SNMPv3 MPM currently recognizes the msgSecurityParameters and uses
that in its decision.

There is no sub-text; a secure transport model and security model
should be able to work with any version of SNMP message, if the
appropriate parameters are provided. When a secure transport model is
used, tmStateReference provides the msgSecurityParameters for SNMPv1,
SNMPv2c, SNMPv3, and SNMPv99.

If provided, the msgSecurityParameters block from the tmStateReference
takes precedence over the parameters derived from an SNMP message
header. And since we want RADIUS integration, and are providing that
integration at the transport model, not the message version models,
some of the msgSecurityParameters, e.g., the required securityModel,
might be provided by RADIUS.

If a tmStateReference does not exist or does not include the
equivalent of msgSecurityParameters, e.g., when using the traditional
UDP transport mapping, then the current processing rules apply to get
the security parameters from the message header -
msgSecurityModel/Name/Level from the SNMPv3 header or, for SNMPv1 or
SNMPv2c messages, implicitly determine the securityModel from the
message version, securityName from community, and implicitly specify
that securityLevel is noAuthNoPriv. 

dbh

> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Friday, January 25, 2008 7:55 PM
> To: [email-masked]
ACM

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Mon, 28 Jan 2008 09:43:03 -0500

While there is nothing wrong with snmpv3 or the new SNMP management framework, 
there are at least several vendors I know of who use snmpv2c on their NMS systems
and agents and do not yet have snmpv3 capability.  This is not in reference to legacy
NMS systems and legacy internet equipment agents, but about new systems that use XML
and web based southbound interfaces for devices that support current state of the
art internet applications.  In addition, it is worth to mention here that there is
a case where a large customer requested to use SNMPv1 traps for alarm (conditions)
and event messages.  The reason being is not that the SNMPv2 and v3 messages have a problem,
but the SNMPv1 trap message structure with its numbering schema for enterprise traps
fits perfectly with the their alarm and event application environment.

At this point, it may not be a bad idea to poll various vendors and end users on what version
of SNMP they use on their NMS systems and perhaps on some of their agents.  I have
a suspicion that there may be more who are using only the community based model
than many of us expected.  If the number is significant, it will be just as important
to implement SSH for SNMPv2c and v1 as it is for v3 since requirements for SSH
is very likely to be coming soon from end user customers who currently use only
SNMP v2c capable NMS systems. 

Andy Donati
Motorola

-----Original Message-----
From: Bert Wijnen [mailto:[email-masked]] 
Sent: Friday, January 25, 2008 6:34 PM
To: [email-masked]; David Harrington
Cc: [email-masked]
Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM

W.r.t.
> > encompass multiple devices to support contextNames that are local to 
> > a specific contextEngineID,
> 

I do know that most agents were/are multi-lingual (SNMPv1,v2c,v3) but there are not that many NMSes that are SNMPv3 capable as far as I know. Now... I must admit that I have not kept track of that too closely in the last few years.

Bert

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 28 Jan 2008 19:55:46 +0100

You cannot actually have such a downref. 

Of course, this is not the only issue that I do not like in this
proposal. 

Dan

> Sent: Saturday, January 26, 2008 2:55 AM
> To: [email-masked]
> Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM
> 
> Hi -
> 
> How would having a normative dependency on an experimental 
> (SNMPvc) RFC affect this work process-wise?
> 
> Or is the real sub-text of this discussion that SNMPv3 should 
> be withdrawn from the standards track?
> 
> Randy
> 
> 
> This email was protected during delivery to Avaya with TLS encryption
> 
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 28 Jan 2008 16:20:15 -0500

Hi Dan,

I am curious as to what other issues you do not like in this proposal.

The SNMPv3 architecture was designed to permit various models to be
used together in different combinations. I am trying to make it
possible to use different security models with different message
versions. I think that is very consistent with the SNMPv3 WG
intentions of modularity. 

The one place where the SNMPv3 WG found a need to "bind" models was
between the SNMPv3 message format and the named security models,
because the security parameters that are needed by the different
security models are passed in the SNMPv3 message header. Unfotunately,
we also needed to bind SNMPv1 and the SNMPv1 security model directly,
and the SNMPv2c message format to the SNMPv2 security model directly,
because the security parameters are extracted from the fields of the
message headers and we had no way to pass securityModel in the
headers.

With secure transports, the security parameters are actually provided
by the transport layer protocol security - all except the
securityModel parameter. The proposal is to make the transport model
responsible for identifying the securityModel that will know how to
properly process the securityparameters provided. This is equivalent
to what the SNMPv3 message header provides now.

And by doing this in the transport model, we can use RADIUS to provide
during authentication some centralized control over the securityModel
runtime decision that is so important to data access authorization.

dbh 

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, January 28, 2008 1:56 PM
> To: Randy Presuhn; [email-masked]
ACM