Subject: [Isms] ISMS Encryption Requirement

From: Kaushik Narayan <[email-masked]>
Date: Mon, 18 Oct 2004 11:58:51 -0700

Hi All,

We had a question about ISMS being able to provide one of the features
that we think is important for SNMPv3. It is ability in SNMPv3 to decide
whether a packet needs to be encrypted on a per-packet basis, rather
than on a per-"session" basis.

It is essential that agents need to authenticate every packet
but however, the same is *not* true for encryption.  For example, the
ifInOctets counter for the interface over which the SNMP request is
sent is not secret -- anybody with access to the wire can count such
packets.  It is entirely a waste of the agent's resources to encrypt
an SNMP packet which contains (only) that ifInOctets counter.  The same
is true for a significant number of other MIB objects.  On the other hand,
some packets contain the values of MIB objects which *are* secret and
do need to be encrypted.  In other words, the ability to decide whether
a packet needs to be encrypted ought to be on a per-packet basis, not on
a per-"session" basis.  Of course:

- some agents have lots of CPU-power and can afford to encrypt/decrypt
   every SNMP packet send/received, or
- some net-administrators are naturally paranoid and will want to encrypt
   all SNMP packets, or
- some management applications send/receive no more packets to/from
   an SNMP agent than they send/receive CLI commands over encrypted
   SSH sessions, and because that number is small enough, the CPU-power
   taken to encrypt/de-crypt is not significant burden.

But ... for agents where none of the above bullets are true, then ISMS
needs to offer the capability for an agent to be configured to accept and
respond to authenticated but unencrypted packets for a number of MIB objects
which are not secret and provide encryption for certain other sensitive
MIB objects as part of the same "session".  Otherwise, many of today's
SNMP agents and/or management applications will break due to a lack of
CPU-power.

regards,
   kaushik!

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Oct 2004 22:11:36 +0200

> than on a per-"session" basis.

Let me disagree - at least to start a debate about this. ;-)
 
>   taken to encrypt/de-crypt is not significant burden.

Who decides whether a certain packet needs encryption? If it is simply
the type of application (say MRTG), then why is using an unencrypted 
session not working? If it is more than the type of the application,
who actually makes the decision? The application writer? The operator?
But in both cases, why is it not sufficient to have an encrypted and 
an unencrypted authenticated channel to choose from?
 
/js

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

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 18 Oct 2004 13:44:29 -0700

>>>>> On Mon, 18 Oct 2004 11:58:51 -0700, Kaushik Narayan <[email-masked]> said:

Kaushik> We had a question about ISMS being able to provide one of the
Kaushik> features that we think is important for SNMPv3. It is ability
Kaushik> in SNMPv3 to decide whether a packet needs to be encrypted on
Kaushik> a per-packet basis, rather than on a per-"session" basis.

I think many of the solutions proposed fit this bill.  SBSM certainly
handles this and I'd have to go back and look to be certain, but I
believe EUSM does too.

-- 
Wes Hardaker
Sparta

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 18 Oct 2004 14:11:04 -0700

Hi Juergen,

Please find my response inline.

>Let me disagree - at least to start a debate about this. ;-)

Per packet application of the securityLevel is inherent to the SNMPv3
architecture. From STD62

"Every message has an associated securityLevel.  All Subsystems
(Message Processing, Security, Access Control) and applications are
REQUIRED to either supply a value of securityLevel or to abide by the
supplied value of securityLevel while processing the message and its
contents."

Are you suggesting that this behavior need not be retained with ISMS.
>an unencrypted authenticated channel to choose from?

The per-packet decision is made by a combination of things, in most
cases driven by the NM application based on the MIB objects, operator
policy and agent capability.

Correct me if I am wrong but per your suggestion, each SNMP "session"
would have to negotiate two separate protection channels (encrypted and
authenticated w/o encryption) and for every packet the SNMP engine will
use the appropriate channel based on the desired securityLevel. It would
be more optimal to negotiate authentication and privacy keys and let SNMP
engine apply the per-packet protection as described in STD62.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 18 Oct 2004 17:19:48 -0400

Hi,

I suspect that different solutions will support this to differing
degrees. If a session is all-encrypted or no-encryption, it might be
possible to open two sessions. Of course, both agent and manager may
need to understand how to handle two sessions with different security
properties.

I suspect that most operators, most agent implementors, and most
application implementors would choose the simpler path of encrypting
everything in the session. For vendors who produce products with
inadequate CPU, they will need to worry about whether their
competitors will do a better job. 

Having been on both the agent side and the manager side, and having
listened to operators who want simple solutions, I don't think ISMS
should require all proposed solutions to make encryption per-packet.
The goal of ISMS is to make it easier to configure the security of
SNMPv3. Requiring complexity that most equipment and application
developers might not support in their products, and most operators
wouldn't use if it was supported in products seems to be
counter-indicated.

My $.02

dbh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kaushik Narayan
Sent: Monday, October 18, 2004 2:59 PM
To: [email-masked]
Subject: [Isms] ISMS Encryption Requirement

Hi All,

We had a question about ISMS being able to provide one of the features
that we think is important for SNMPv3. It is ability in SNMPv3 to
decide whether a packet needs to be encrypted on a per-packet basis,
rather than on a per-"session" basis.

It is essential that agents need to authenticate every packet but
however, the same is *not* true for encryption.  For example, the
ifInOctets counter for the interface over which the SNMP request is
sent is not secret -- anybody with access to the wire can count such
packets.  It is entirely a waste of the agent's resources to encrypt
an SNMP packet which contains (only) that ifInOctets counter.  The
same is true for a significant number of other MIB objects.  On the
other hand, some packets contain the values of MIB objects which *are*
secret and do need to be encrypted.  In other words, the ability to
decide whether a packet needs to be encrypted ought to be on a
per-packet basis, not on a per-"session" basis.  Of course:

- some agents have lots of CPU-power and can afford to encrypt/decrypt
   every SNMP packet send/received, or
- some net-administrators are naturally paranoid and will want to
encrypt
   all SNMP packets, or
- some management applications send/receive no more packets to/from
   an SNMP agent than they send/receive CLI commands over encrypted
   SSH sessions, and because that number is small enough, the
CPU-power
   taken to encrypt/de-crypt is not significant burden.

But ... for agents where none of the above bullets are true, then ISMS
needs to offer the capability for an agent to be configured to accept
and respond to authenticated but unencrypted packets for a number of
MIB objects which are not secret and provide encryption for certain
other sensitive MIB objects as part of the same "session".  Otherwise,
many of today's SNMP agents and/or management applications will break
due to a lack of CPU-power.

regards,
   kaushik!

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Oct 2004 23:36:29 +0200

> supplied value of securityLevel while processing the message and its

To me, this text only says that every message has an associated
securityLevel. It does not say how that maps to sessions (since
the notion of sessions does not exist in STD62).
 
> policy and agent capability.

I would be curios to see some piece of code or logic that does this
sort of thing. How do you combine the three ingredients you have listed
above? What does agent capability mean here??
 
> engine apply the per-packet protection as described in STD62.

More optimal with regard to what?

Encryption of small packets by itself is not very efficient. Breaking
communication into pieces, some of which are encrypted while other are
not might in some situations be more expensive than using an encrypted
channel for everything. The measurements reported in the SNMP over TLS 
paper showed that SNMP over TLS performed better than SNMP over TCP 
with USM, basically because you share session state and do not have to 
treat each packet as an isolated event. Of course, you can build 
scenarios where you reach other results.

The point is that we should start to be more precise and define the 
metrics and the scenario we are talking about if we claim something to 
be optimal or better. This is especially important since SNMP sometimes
shows rather poor performance for tasks other than regular polling
of a handful of variables that fit into one PDU. For those interested,
there is a paper forthcoming in the IEEE eTNSM fall issue where you 
can see results from reading the interface table or doing SNMP walks 
on real-world agents. The work was driven by the desire to understand 
the impact of web services on CPU and memory requirements. As a side 
effect, some measurements of real-world SNMP agents were done and 
the results of these measurements alone are fun to look at.

/js

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 18 Oct 2004 15:29:55 -0700

It's not just about CPU power of the device but the percentage of CPU
cycles that are spent on network management. There isn't much
value in using encryption for a performance management system
polling PEs for performance data on thousands of interfaces every
ten minutes,it  just adds significant overhead to processing of the
packet.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 18 Oct 2004 18:40:21 -0400

Hi,
 
Let me address this three ways.
 
1) As one of the architects of SNMPv3, I believe you're interpreting
the text from RFC3411 section 3.4.3 incorrectly. Please read it more
closely.
 
Each designed subsytem must **either** supply a value of
securityLevel, **or** abide by the supplied value of SecurityLevel.
The architecture described in RFC3411 was designed to be compatible
with the existing architecture of SNMPv1; i.e. SNMPv1 could be
described using the RFC3411 architecture.
SNMPv1 has no capability of specifying the securityLevel in a message,
but it has a supplied value of securityLevel - noAuthNoPriv, as per
BCP 74, RFC3584.
 
You seem to be arguing that it should be a requirement that all
subsystems must be designed to abide by a supplied value of
SecurityLevel, and thus all proposals must be able to supply a
securityLevel per packet. That is NOT an architectural requirement of
RFC3411.
 
2) To make this a requirement of ISMS would require a change to the
existing RFC3411 architecture requirements, or limit ISMS to a subset
of legal RFC3411 designs.
It would not necessarily be optimal to make this a requirement. 
 
A large part of the goal of ISMS is to leverage existing security
solutions, to minimize the need to configure additional security
solutions. It is not a goal to design another SNMP-specific security
solution.
If the existing technologies that are widely deployed could not be
used because of the requirement you would like to require, then you
would be defeating the purpose of ISMS.
 
3) It could be very beneficial to security and ease-of-use if the same
technologies could be used to provide security for multiple NM
interfaces within a system. Non-SNMP interfaces typically do not
support the per-packet selection of encryption, to my knowledge.
Common protocols in wide use for NM security include SSH for the CLI,
and TLS or SSL for web-based interfaces, and I don't believe these
support the feature. NetConf does not appear to be planning to support
this feature either. The added complexity may not be justified in
enough environments to make this "sometimes" benefit worth the cost.
 
Therefore, to require that this feature be supported in all ISMS
proposals would be to again isolate SNMP from the types of security
used in most other NM interfaces. That is not desirable.
 
David Harrington

[email-masked] 

co-chair SNMPv3 WG, concluded

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kaushik Narayan
Sent: Monday, October 18, 2004 5:11 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Isms] ISMS Encryption Requirement

Hi Juergen,

	On Mon, Oct 18, 2004 at 11:58:51AM -0700, Kaushik Narayan

"Every message has an associated securityLevel.  All
Subsystems
(Message Processing, Security, Access Control) and applications are
REQUIRED to either supply a value of securityLevel or to abide by the
supplied value of securityLevel while processing the message and its
contents."

CPU-power
	>   taken to encrypt/de-crypt is not significant burden.
	
	Who decides whether a certain packet needs encryption? If it
is simply
	the type of application (say MRTG), then why is using an
unencrypted 
	session not working? If it is more than the type of the
application,
	who actually makes the decision? The application writer? The
operator?
	But in both cases, why is it not sufficient to have an
encrypted and 
	an unencrypted authenticated channel to choose from?

Correct me if I am wrong but per your suggestion, each SNMP "session" 
would have to negotiate two separate protection channels (encrypted
and 
authenticated w/o encryption) and for every packet the SNMP engine
will
use the appropriate channel based on the desired securityLevel. It
would
be more optimal to negotiate authentication and privacy keys and let
SNMP
engine apply the per-packet protection as described in STD62.

regards,
  kaushik!

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

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 18 Oct 2004 15:49:09 -0700

>above? What does agent capability mean here??

Predominantly the decision is driven by the SNMP objects. For e.g. the
performance sub-system will work with objects that won't need encryption
whereas we need encryption for most configuration objects. Typically operator
policy such as "encryptAll" will over-ride this behavior. In some cases,
especially for monitoring of modems and access points, it does not make
sense to use encryption and the option to set explicit encryption policies
is not available for operators.

>scenarios where you reach other results.

I am not sure that using an encrypted TLS channel for everything will
work for use cases in performance management wherein we collect
massive amounts of non sensitive data at periodic intervals.

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 18 Oct 2004 17:55:50 -0700

Hi David,

Sorry for my narrow interpretation of RFC3411.

I was suggesting that the capability to use selective encryption for SNMPv3
is extremely useful in use cases around periodic data collection which
is what SNMP is predominantly used for currently (in addition to fault
management). NetConf and CLI access are predominantly used for configuration
management that deal with data that is far more sensitive and far less
voluminous and there is really no need to perform selective encryption.

I am also not proposing that we stop evaluating existing security technologies
for the use within ISMS. Infact most of the proposals on the table seem to
be based on existing security technologies. Essentially, I think the ability
to provide selective protection should be considered as a requirement to 
evaluate
the proposals in addition to other requirements.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 18 Oct 2004 21:18:37 -0400

I think the ability to provide selective protection should be
considered as a desirable feature to evaluate the proposals in
addition to other requirements and desirable features.

David Harrington
[email-masked]

-----Original Message-----
From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Monday, October 18, 2004 8:56 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Isms] ISMS Encryption Requirement

Hi David,

I was suggesting that the capability to use selective encryption for
SNMPv3 is extremely useful in use cases around periodic data
collection which is what SNMP is predominantly used for currently (in
addition to fault management). NetConf and CLI access are
predominantly used for configuration management that deal with data
that is far more sensitive and far less voluminous and there is really
no need to perform selective encryption.

I am also not proposing that we stop evaluating existing security
technologies for the use within ISMS. Infact most of the proposals on
the table seem to be based on existing security technologies.
Essentially, I think the ability to provide selective protection
should be considered as a requirement to evaluate the proposals in
addition to other requirements.

regards,
   kaushik!

>Each designed subsytem must **either** supply a value of
securityLevel, 
>**or** abide by the supplied value of SecurityLevel.
BCP 
>74, RFC3584.

>If the existing technologies that are widely deployed could not be
used 
>because of the requirement you would like to require, then you would
be 
>defeating the purpose of ISMS.
>

>         > packets.  It is entirely a waste of the agent's resources
to 
>         > is true for a significant number of other MIB objects.  On

>the other hand,
>         > some packets contain the values of MIB objects which *are*

>secret and
>         > a packet needs to be encrypted ought to be on a per-packet

>basis, not on
>         > - some management applications send/receive no more
packets 
>to/from

and 
will 
>would be more optimal to negotiate authentication and privacy keys
and 
>let SNMP engine apply the per-packet protection as described in
STD62.

---

From: Robert Story <[email-masked]>
Date: Mon, 18 Oct 2004 21:23:36 -0400

On Mon, 18 Oct 2004 11:58:51 -0700 Kaushik wrote:
KN> We had a question about ISMS being able to provide one of the features
KN> that we think is important for SNMPv3. It is ability in SNMPv3 to decide
KN> whether a packet needs to be encrypted on a per-packet basis, rather
KN> than on a per-"session" basis.

My impression of Kaushik's message was that he wants the decision to be made
automatically (like setting up VACM views to define which objects need/don't
need encryption). That doesn't seem workable, especially if done on the agent
side, as sending a response packet with a different securityLevel than the the
request packet would be just plain wrong.

On Mon, 18 Oct 2004 15:49:09 -0700 Kaushik wrote:
KN> At 02:36 PM 10/18/2004, Juergen Schoenwaelder wrote:
KN> > > "Every message has an associated securityLevel.
KN> >
KN> >To me, this text only says that every message has an associated
KN> >securityLevel. It does not say how that maps to sessions (since
KN> >the notion of sessions does not exist in STD62).

I think this is a key point. I think what the securityLevel of a session should
be a soft of max-access. If you create a session with noAuthNoPriv, then you
wouldn't be able to send encrypted packets. But if you start a session with
AuthPriv, I don't see any reason why you shouldn't be able to send a pdu with a
securityLevel of AuthNoPriv, thus requesting that there be no encryption for
that packet. This, however, is a decision on the NM side, and would be at the
application level, not the protocol level.

If the ISMS RFC does let the session securityLevel function as a max-access
level, then I think the view-based packet security level is a neat idea for the
application vendor. Put in a feature request. <shameless plug> Or, if you use
and open source platform (*cough* net-snmp *cough*), submit a patch! :-)
</shameless plug>.

-- 
Robert Story; NET-SNMP Junkie
<irc://irc.freenode.net/#net-snmp>   <http://www.net-snmp.org/>

You are lost in a twisty maze of little standards, all different.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 18 Oct 2004 20:06:07 -0700

David> I think the ability to provide selective protection should be
David> considered as a desirable feature to evaluate the proposals in
David> addition to other requirements and desirable features.

I agree.  I shouldn't be a requirement, but as a desire I think it
should be there as well.

-- 
Wes Hardaker
Sparta

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 18 Oct 2004 20:12:25 -0700

>>>>> On Mon, 18 Oct 2004 21:23:36 -0400, Robert Story <[email-masked]> said:

Robert> My impression of Kaushik's message was that he wants the
Robert> decision to be made automatically (like setting up VACM views
Robert> to define which objects need/don't need encryption). That
Robert> doesn't seem workable, especially if done on the agent side,
Robert> as sending a response packet with a different securityLevel
Robert> than the the request packet would be just plain wrong.

I don't think thats what he meant at all.  I'm quite sure he meant
that if you start a SBSM or TLS or EUSM or ... session that you should
be able to transmit packets under that session as either authNoPriv or
authPriv.  This is possible in SBSM and EUSM (I think) today, but will
likely not be possible with TLS (though maybe with DTLS?).

Robert> I think this is a key point. I think what the securityLevel of
Robert> a session should be a soft of max-access. If you create a
Robert> session with noAuthNoPriv, then you wouldn't be able to send
Robert> encrypted packets. But if you start a session with AuthPriv, I
Robert> don't see any reason why you shouldn't be able to send a pdu
Robert> with a securityLevel of AuthNoPriv, thus requesting that there
Robert> be no encryption for that packet. This, however, is a decision
Robert> on the NM side, and would be at the application level, not the
Robert> protocol level.

I suspect that many potential protocols (SBSM included) don't really
map to that statement.  EG, in SBSM during setup the security level
flags are ignored by the security and have to be till negotiation is
finished.

-- 
Wes Hardaker
Sparta

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Oct 2004 11:31:13 +0200

> voluminous and there is really no need to perform selective encryption.

I heard operators saying that (a) MIB instrumentation often come too 
late and that (b) they often trust CLI numbers more than SNMP numbers.
So there might be more scripted CLI access to collect data than you 
might expect.

If you talk about voluminous data, do you mean that (i) you talk to
lots of devices and each device gives you little pieces of data, but
the total is voluminous, or do you mean that (ii) you retrieve large
amounts of data from the average device, so the total is voluminous
or (iii) are you saying that the retrieved data over some time tends 
to be voluminous.

/js

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 19 Oct 2004 14:01:46 +0200

> So there might be more scripted CLI access to collect data than you

For periodical data collection, my observations is that several big
operators prefer most and trust most log files over ftp, particularly
if its a lot of data per managed node.

    Juergen

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 19 Oct 2004 10:44:40 -0400

>but however, the same is *not* true for encryption.

While I agree that it's not essential ... you should consider _very
carefully_ the security implications of this.  Let me give you a
cautionary tale (the origin of it predates my involvement, but I
was involved in the aftermath).

Many many moons ago, various parties were hammering out the specification
for Telnet Encryption (this eventually became RFC 2946).  As part of
this, there were a number of Telnet vendors/implementors involved in
this process.

A number of vendors wanted the ability to turn on and off encryption on
the fly; the reasoning at the time was that they didn't want to incur
the CPU overhead of encrypting and decrypting _everything_ (this was in
the era of 68000-based Macintoshes), and that not everything in the
Telnet stream was important.  For example, some vendors planned on only
encrypting passwords and the like.  So, placed into the Telnet protocol
was the ability to turn on and off encryption on the fly (a feature
which is unique among stream-based encrypting protocols, AFAIK).

In retrospect, this turned out to be a HUGE mistake.  The reasons are
multiple:

- It turned out impossible in practice to determine when a password was
  being entered (since most telnet streams are not linemode and thus
  echo is handled on the server side).

- Because this complicated the protocol, some vendors ended up implementing
  this feature incorrectly or incompletely (but because it wasn't being
  used in practice, see above, no one really understood this at the time).

- It made it hard to enforce a consistant server-side policy (e.g, requiring
  the use of encryption), partly due to the nature of the protocol and
  partly because the implementations had to be so complicated to support
  this protocol feature.

- It ended up creating a bunch of security vulnerabilities in the protocol
  which required a protocol revision to correct some of them (since
  you have to negotiate encryption before encryption starts, an attacker
  could remove the part of the stream that negotiates encryption).  Not
  all of them are correctable, unfortunately (but thankfully the more
  important ones are).

Other protocols learned the hard lessons of encrypted Telnet, and now
nearly all encrypted-stream protocols (that I'm aware of) simply start
encrypting as soon as possible, and have no capability to turn this
encryption off.  This simplifies the protocol and the implementation,
and reduces the possibility of vulnerabilites.

Now, not all of these things apply to SNMP, of course (for one, SNMP is
a datagram-based protocol).  But when you get into deciding that some
data isn't worth encrypting and maybe you should only encrypt _part_ of
it ... well, all I can say is that other protocols have decided that in
the long run, it's better to encrypt everything.  If the WG decides
that only partial encryption is desired, then that's fine ... but I
feel I would be remiss if I didn't point out that we should think _very
hard_ about what exactly this means for security.

--Ken

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 19 Oct 2004 10:09:45 -0700

Hi Robert,

Please find my reply inline.

>request packet would be just plain wrong.

I was suggesting that SNMPv3 currently allows a management application
to support selective encryption within a session, i.e. certain requests can
be sent with authPriv and certain others within authNoPriv. This is an
important ability since there are significant implications on agent
performance if we were to encrypt all data within a session.
This ability to provide selective encryption is supported by SBSM and
EUSM but difficult to achieve with the use of transport level protection like
SNMPv3 over TLS.

regards,
  kaushik!

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 19 Oct 2004 10:57:39 -0700

Hi Juergen,

Please find my reply in line.

>or (iii) are you saying that the retrieved data over some time tends

With performance collection the data is voluminous since you collect large 
amounts
of data at periodic intervals, for e.g. collection of a objects in the IF 
MIB on PE routers
with tens of thousands interfaces every 10 minutes. We have quite a few 
devices that
support bulk files upload using FTP for such use cases but there are a few 
that still
need to be polled periodically via SNMP.

regards,
   kaushik!

---

From: Robert Story <[email-masked]>
Date: Tue, 19 Oct 2004 14:10:40 -0400

On Mon, 18 Oct 2004 20:12:25 -0700 Wes wrote:
WH> >>>>> On Mon, 18 Oct 2004 21:23:36 -0400, Robert Story
WH> ><[email-masked]> said:
WH> 
WH> Robert> My impression of Kaushik's message was that he wants the
WH> Robert> decision to be made automatically [...]
WH> 
WH> I don't think thats what he meant at all.

I guess I misunderstood "[...] the decision is driven by the SNMP objects". I
interpreted that to mean a decision make as the packet were processed, not by
the NM before sending the packet. Sorry for the confusion!  (I still think it's
an interesting idea on the NM side.)

WH> Robert> I think what the securityLevel of a session should be a sort
WH> Robert> of max-access.
WH> 
WH> I suspect that many potential protocols (SBSM included) don't really
WH> map to that statement.  EG, in SBSM during setup the security level
WH> flags are ignored by the security and have to be till negotiation is
WH> finished.

I was talking about sending packets once the session was established.

And if sessions don't have a max-access, should they? e.g. If a authPriv
packet is sent via SBSM, and no encryption keys were negotiated for the
session, shouldn't that be rejected (as noAuth packets are)?

Obviously if the solution relies on encryption at the transport level, then
authNoPriv will continue to be encrypted and consume extra CPU resources.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Oct 2004 20:11:48 +0200

> need to be polled periodically via SNMP.

So if FTP works for you (which actually establishes multiple
connections), I would say session based SNMP should work as well. ;-)

Note: I see your point. I am just trying to figure out what is really
being done and if people talk about large sets of SNMP MIB variables
(whatever means large here), I know from experience and actual
measurements that SNMP is really a poor protocol to retrieve such
data sets (according to my definition of large ;-).

/js

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 19 Oct 2004 12:39:00 -0700

>>>>> On Tue, 19 Oct 2004 14:10:40 -0400, Robert Story <[email-masked]> said:

Robert> And if sessions don't have a max-access, should they? e.g. If
Robert> a authPriv packet is sent via SBSM, and no encryption keys
Robert> were negotiated for the session, shouldn't that be rejected
Robert> (as noAuth packets are)?

As currently defined, thats not possible actually.  Now, there was
discussion in the past about not requiring encryption but to date the
SBSM draft says you must support at least one encryption alg.

Robert> Obviously if the solution relies on encryption at the
Robert> transport level, then authNoPriv will continue to be encrypted
Robert> and consume extra CPU resources.

In SBSM, you must negotiate encryption and keys but you don't have to
use it once a session is up.

-- 
Wes Hardaker
Sparta

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 19 Oct 2004 20:51:53 -0700

>>>>> On Tue, 19 Oct 2004 10:44:40 -0400, Ken Hornstein <[email-masked]> said:

Ken> - It made it hard to enforce a consistant server-side policy
Ken> (e.g, requiring the use of encryption), partly due to the nature
Ken> of the protocol and partly because the implementations had to be
Ken> so complicated to support this protocol feature.

Ken,

Thanks for the good summary on past problems.  I'm certainly glad we
have a decent security-guy as a chair!

One comment though (read: not a rebuttal): SNMPv3 already has an
access control mechanism in place today (VACM) that allows you use
fine grained control over which objects can be accessed and which can
not if encryption is not turned on.  Because of the nature of
well-structured OID trees, you actually have the ability to have
fairly precise control over what is allowed and disallowed to go over
plain-text versions.  That being said, operator error or lack of
understanding is sure to be a problem.  I suspect that many people
today have a minimum authNoPriv requirement on most of their MIB tree
and don't rethink the policy every time they upload a new firmware
and it is suddenly capable of releasing more sensitive data than the
previous firmware release.  Very few people do the "right" think and
only turn on access to objects that they want.  Instead, most people
turn on access to everything and attempt to deny things they don't
want released which is not forward-future thinking.

-- 
Wes Hardaker
Sparta

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Oct 2004 11:56:55 +0200

On Tue, Oct 19, 2004 at 08:51:53PM -0700, Wes Hardaker wrote:
 
> That being said, operator error or lack of
> understanding is sure to be a problem.

In many cases, the operator simply has no chance because a) the SNMP
application of choice does not document what it needs to function and
b) the MIB modules, especially some proprietary ones, do not really
explain in enough details what the various objects really do. So even
if the operators would have the time to dive into the details (which
they don't have generally), they would have no chance of success.
Fine grained VACM access control is IMHO a myths.

[And thanks to Ken for the nice telnet story - we should learn from it.]

/js

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 20 Oct 2004 07:56:13 -0700

>>>>> On Wed, 20 Oct 2004 11:56:55 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> Fine grained VACM access control is IMHO a myths.

It'd be fine if people did the proper thing from a security
perspective:  Turn on only what you need.

  exclude .1.3
  include ifTable

instead of the more typical

  include .1.3

-- 
Wes Hardaker
Sparta

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 20 Oct 2004 15:00:49 -0400

>not if encryption is not turned on.

Sure, and that part is _very_ cool.  But that's not actually what I'm
worried about.

Let's say that we want to (within one as-yet-undefined-future-SNMPv3-
security-model "session") have some MIB elements be sent encrypted, and
some sent unencrypted.  Let's also say that we're doing a
GetBulkRequest.

We could be put in the case where not only is the change from encrypted
to not encrypted happens between different PDUs in the same "session"
(I'm using the word "session" loosely here, some security models may
not have sessions), but the change would happen _within the same PDU_.
Now, of course we could specify that is not allowed.  But even saying
_that_ means we have to complicate the GetBulkRequest code to know that
it needs to process these MIB elements in a different way.

Again, this is hypothetical.  And I think that if you want to start a
"session" where you don't have encryption and you are depending on VACM
to not return parts of the MIB tree that have to be encrypted is fine.
But switching back and forth can get complicated, and experience has
taught us that complexity can be the enemy of security.

--Ken

---

From: Robert Story <[email-masked]>
Date: Thu, 21 Oct 2004 10:26:58 -0400

On Wed, 20 Oct 2004 15:00:49 -0400 Ken wrote:
KH> Let's say that we want to (within one as-yet-undefined-future-SNMPv3-
KH> security-model "session") have some MIB elements be sent encrypted, and
KH> some sent unencrypted.  Let's also say that we're doing a
KH> GetBulkRequest.
KH> 
KH> We could be put in the case where not only is the change from encrypted
KH> to not encrypted happens between different PDUs in the same "session"

This is how I interpreted Kaushik's first message.

KH> (I'm using the word "session" loosely here, some security models may
KH> not have sessions), but the change would happen _within the same PDU_.
KH> Now, of course we could specify that is not allowed.

And this was the next logical step in that line of thought. Although I don't
think anyone was suggesting that only certain parts of the PDU should be
encrypted.

What I was going to suggest, before it was determined that Kaushik didn't mean
what I thought he meant, was that instead of not allowing different levels
within the same PDU, that each object's security level be used to determine the
minimal security level needed for the whole PDU. So if all the varbinds only
require authNoPriv, then PDU need not be encrypted. But if even one requires
authPriv, then the entire PDU must be encrypted.

But this still leaves open the possibility of a response PDU with a different
security level than the request PDU, which was my initial objection.

KH> But even saying _that_ means we have to complicate the GetBulkRequest code
KH> to know that it needs to process these MIB elements in a different way.

Not just GetBulk, but GetNext as well. Like I said, for get/set requests, the
manager should be able to determine the appropriate level before sending a
request. (though a manager and agent might disagree on what that level should
be. but that's getting into policy.)

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 21 Oct 2004 12:07:33 -0400

Hi,

SNMPv3 does not support per-varbind securityLevels, only message-based
securityLevels.

David Harrington
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Story
Sent: Thursday, October 21, 2004 10:27 AM
To: Ken Hornstein
Cc: [email-masked]
Subject: Re: [Isms] ISMS Encryption Requirement

On Wed, 20 Oct 2004 15:00:49 -0400 Ken wrote:
KH> Let's say that we want to (within one 
KH> as-yet-undefined-future-SNMPv3- security-model "session") have
some 
KH> MIB elements be sent encrypted, and some sent unencrypted.  Let's 
KH> also say that we're doing a GetBulkRequest.
KH> 
KH> We could be put in the case where not only is the change from 
KH> encrypted to not encrypted happens between different PDUs in the
same "session"

KH> (I'm using the word "session" loosely here, some security models
may 
KH> not have sessions), but the change would happen _within the same
PDU_.
KH> Now, of course we could specify that is not allowed.

And this was the next logical step in that line of thought. Although I
don't think anyone was suggesting that only certain parts of the PDU
should be encrypted.

What I was going to suggest, before it was determined that Kaushik
didn't mean what I thought he meant, was that instead of not allowing
different levels within the same PDU, that each object's security
level be used to determine the minimal security level needed for the
whole PDU. So if all the varbinds only require authNoPriv, then PDU
need not be encrypted. But if even one requires authPriv, then the
entire PDU must be encrypted.

But this still leaves open the possibility of a response PDU with a
different security level than the request PDU, which was my initial
objection.

KH> But even saying _that_ means we have to complicate the 
KH> GetBulkRequest code to know that it needs to process these MIB
elements in a different way.

Not just GetBulk, but GetNext as well. Like I said, for get/set
requests, the manager should be able to determine the appropriate
level before sending a request. (though a manager and agent might
disagree on what that level should be. but that's getting into
policy.)

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Oct 2004 09:44:19 -0700

>>>>> On Thu, 21 Oct 2004 10:26:58 -0400, Robert Story <[email-masked]> said:

Robert> Although I don't think anyone was suggesting that only certain
Robert> parts of the PDU should be encrypted.

No, and in fact it would violate part of the charter: to not modify
the SNMPv3 architecture (which states that the scopedPDU is what gets
encrypted or not; not pieces of it).

Robert> What I was going to suggest, before it was determined that
Robert> Kaushik didn't mean what I thought he meant, was that instead
Robert> of not allowing different levels within the same PDU, that
Robert> each object's security level be used to determine the minimal
Robert> security level needed for the whole PDU. So if all the
Robert> varbinds only require authNoPriv, then PDU need not be
Robert> encrypted. But if even one requires authPriv, then the entire
Robert> PDU must be encrypted.

That's also against the v3 architecture, as the security level flags
are defined fairly explicitly such that if you send a authNoPriv
message then you should not expect a authPriv response (or
vice-versa).  It's not USM specific, its more global to the
architecture than that (grep for securityLevel in 341?).

Robert> But this still leaves open the possibility of a response PDU
Robert> with a different security level than the request PDU, which
Robert> was my initial objection.

Yep.  Not even in the possibility range, according to the charter
(and, of course, my humble opinion).

-- 
Wes Hardaker
Sparta

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 21 Oct 2004 10:14:09 -0700 (PDT)

HI,

First, when one does a GET or a SET, the instance of management info
that is being accessed is known by the manager, and, thus, the privLevel
in the message can be set based on the preceived sensitivity by the
manager of the data. (Of course, if the VACM tables require a level
"higher" than specified by the manager, then access is not allowed.)
However, on GETNEXT and GETBULK, the actual instance of management
info is not always deterministically known by the manager when
the request is sent. What instance is returned (if any) is based
on both what instances exist, and the configuration of the VACM
tables. That is, if instances exist, but are "not in the view"
for the privLevel specified in the request, then the instances
are "skipped over". Thus, the description below about choosing
a privLevel for the response based on the highest level of
any accessed instance is a change in the behavior as specified
by VACM. Of course a new access control model could be proposed
that would have the behavior as described below. For the ISMS
work, this is out of scope of the charter. 

Secondly, back to the high level question of whether or not
it is desirable and/or a requirement for a manager to be able
to specifify the privLevel in each message, here are my thoughts...

a) Using IPSEC, SSH, or SSL/TLS to provide security services
"below" the SNMP message creates a fundamental problem to the
current model of SNMP. SNMP VACM uses the "securityName"
and the "securityLevel" to determine if access is allowed.
The securityLevel is contained in _every_ SNMPv3 message.
How the securityName is provided is security model dependent,
and for USM it is in every SNMPv3 message, where for SBSM,
it specified during session setup, and associated with
the session identifier (which is specified in each SNMPv3/SBSM
message). But with IPSEC, SSH, and SSL/TLS securityName
and securityLevel is determined "below" the application
level, and any proposal for a security model using them
needs to specify how this info is made available to the SNMPv3
message processing, and how it is used. That is, if a
(IPSEC, SSH, or SSL/TLS) session is set up with encryption,
is the priv bit always (or never) set in the msgFlags field,
and is the PDU never (or always) encrypted.

b) Current definitions of SNMPv3 message processing and
VACM allow requestor to set the security level only
on a per-message and not per-varbind level.

> be. but that's getting into policy.)

Regards,
/david t. perkins

---

From: Robert Story <[email-masked]>
Date: Thu, 21 Oct 2004 13:27:34 -0400

On Thu, 21 Oct 2004 09:44:19 -0700 Wes wrote:
WH> Robert> Although I don't think anyone was suggesting that only certain
WH> Robert> parts of the PDU should be encrypted.
WH> 
WH> No, and in fact it would violate part of the charter: to not modify
WH> the SNMPv3 architecture (which states that the scopedPDU is what gets
WH> encrypted or not; not pieces of it).

We are all wasting our time here, arguing about something that nobody has
proposed that we do. But my curiosity got the better of me.

Based on my ignorant poking about in the specs, I think it could probably be
finagled if someone really wanted to (and I'm not that someone). In particular:

RFC 3411, A.1.1:

   For privacy, the Security Model defines what portion of the message
   is encrypted.

RFC 3412, 6.4 b:

   b) privFlag

      If the privFlag is set, then the securityModel used by the SNMP
      engine which sent the message MUST also protect the scopedPDU in
      an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the
      scopedPDU.  If the privFlag is zero, then the securityModel in use
      does not need to protect the data from disclosure.
      ^^^^^^^^^^^^^

So a security model is not *prohibited* from protecting a packet without the
privFlag set. In theory, couldn't a security model be defined such that an
authNoPriv packet could encrypt portions of the pdu?

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 21 Oct 2004 10:07:58 -0700

Hi Ken,

I understand that it would be much simpler for us to encrypt
all data and given the improvement in ciphers and hardware
based crypto, we could probably get to a point where the
cost of encryption is not significantly higher than the cost of
digest calculation (for authentication).

My concern is that we have a lot of applications of SNMP
where all we do is collect large amounts of data that is
typically not very sensitive and forcing encryption of all that
data will put a severe strain on both the agents and the
manager applications.

The SNMPv3 protocol already provides per-packet securityLevel
handling both part of USM and VACM, I was suggesting that
the new security model for SNMPv3 continue to provide that
capability.

regards,
   kaushik!

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Oct 2004 10:36:13 -0700

>>>>> On Thu, 21 Oct 2004 10:14:09 -0700 (PDT), "David T. Perkins" <[email-masked]> said:

David> a) Using IPSEC, SSH, or SSL/TLS to provide security services
David> "below" the SNMP message creates a fundamental problem to the
David> current model of SNMP. SNMP VACM uses the "securityName"
David> and the "securityLevel" to determine if access is allowed.
David> The securityLevel is contained in _every_ SNMPv3 message.
David> How the securityName is provided is security model dependent,
David> and for USM it is in every SNMPv3 message, where for SBSM,
David> it specified during session setup, and associated with
David> the session identifier (which is specified in each SNMPv3/SBSM
David> message). But with IPSEC, SSH, and SSL/TLS securityName
David> and securityLevel is determined "below" the application
David> level, and any proposal for a security model using them
David> needs to specify how this info is made available to the SNMPv3
David> message processing, and how it is used. That is, if a
David> (IPSEC, SSH, or SSL/TLS) session is set up with encryption,
David> is the priv bit always (or never) set in the msgFlags field,
David> and is the PDU never (or always) encrypted.

Regarding user names: thats not a problem.  As long as the problem of
passing that name upward from the transport to the security model can
be solved then the sec model can return it to the MP and above.

Regarding the secLevel, however, thats a more interesting problem.
The question is: is the seclevel looked at before the security model
gets to it.  Would it be legal for the security model to ignore the
incoming flags and change them before passing them back up?  If not,
its still possible and the security model would need to (MUST) check
the incoming security level flags to make sure they matched the
TLS/whatever session setup and if not drop the message.  Still doable,
either way.  [And Robert just indicated another point which is
interesting in that you might legally be able to have a authNoPriv
message that is actually encrypted via the transport (but not the
other way around of course).]

-- 
Wes Hardaker
Sparta

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 21 Oct 2004 10:36:14 -0700

I was suggesting that new security model for SNMPv3
retain the per-PDU securityLevel.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 21 Oct 2004 11:06:09 -0700

Hi -

> From: "Robert Story" <[email-masked]>
> To: "Wes Hardaker" <[email-masked]>
> Cc: <[email-masked]>
....
> finagled if someone really wanted to (and I'm not that someone). In particular:
...
> authNoPriv packet could encrypt portions of the pdu?
...

Twisted. That certainly wasn't what we had in mind when we came up with
those words, but your reading does seem to hold up in the context of
what is actually in the architecture document.  How something could decide
which bits to encrypt would be left as a difficult exercise for the reader,
since the ASIs don't provide any help there, and the operation of get-next
and get-bulk complicate response generation.  Let's hope the saying
remains true:  when people say "in theory" they mean "not really."  :-)

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 21 Oct 2004 11:17:06 -0700 (PDT)

HI,

Robert - please be careful with SNMP terminology. The term
"SNMP security model" does not include access control.

And yes, we may be wasting time talking about capabilities
that may be possible, but are not used.

I totally agree with JuergenS that in practice, it has
been shown that it is difficult (if not impossible) to
determine which objects (and especially which instances)
a management application accesses so that VACM access
rules can configured accordingly. So, per-varbind doesn't
seem to make a lot a sense.

---

From: Robert Story <[email-masked]>
Date: Thu, 21 Oct 2004 14:28:45 -0400

On Thu, 21 Oct 2004 11:17:06 -0700 (PDT) David wrote:
DTP> And yes, we may be wasting time talking about capabilities
DTP> that may be possible, but are not used.

I'm just exploring an interesting idea. Obviously people are starting to get
annoyed by the off-topic posts, so I'm just going to be quiet now.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 21 Oct 2004 11:38:43 -0700

Hi -

> From: "Ken Hornstein" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, October 20, 2004 12:00 PM
...
> it needs to process these MIB elements in a different way.

Though I don't think it's a good idea to do this, the added complexity for
GetNext / GetBulk processing isn't *that* great if the agent/subagent
infrastructure is doing a naive iteration while evaluating the isAccessAllowed()
decision for each thing that might be returned in a response until it
finds something that would get through.  If isAccessAllowed(authNoPriv)
fails, try isAccessAllowed(authPriv).  It would no more than double the
processing time to get to a varbind, though could result in material being
sent that wasn't wanted.  ("If I had wanted to get the passwords, I'd have
used AuthPriv.")  If the agent/subagent is using more sophisticated techniques,
in which the VACM views are used to skip over excluded subtrees without
iteration, things get a little tangled, with the increase in processing cost
depending on whether the views have the same granularity, but the
code complexity wouldn't be that great.  However, this still doesn't mean
I like the idea at all.

> to not return parts of the MIB tree that have to be encrypted is fine.

That's how things work today, and how getNext / getBulk processing is
defined in RFC 3413.  I'd rather not reopen that work!  :-)

> taught us that complexity can be the enemy of security.

Whole-heartedly agreed, while recognizing that being able to process
security level on a pdu-by-pdu basis is already built into SNMPv3.
If a proposal defines a notion of session, we'll need to understand
whether it defines the minimum, maximum, or simply *the* security
level for the PDUs belonging to that session.  It's also thinkable that
setting up a session just ensures that the keys and identities are
known, and that everything proceeds from there just as it does now.

In any case, I think we'd be better served at this point by drilling into
the specifics of each proposal to make sure we understand what the
various designers have in mind.

Randy