Subject: [Isms] tmsm comments

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Jan 2007 22:17:53 -0800

There was no timezone specified in the call for comments, so I'm going
to assume that midnight my time is appropriate.  Thus, these are 1
hour and 45 minutes early!

In general, I think the document is fine.  I do have various comments
and one major objection and one major concern.

The one marked with ***s I think is a show stopper.

The one marked with ###s is a "bad thing" but I won't be obnoxious
about it.

Architecture of newly created "layer" not clearly spelled out up front?
I guess I'd like to see the diagram in 3.2.1 higher in the doc.

-----
                                               It is possible but
   difficult to define external mechanisms that handle the distribution
   of keys for use by the USM approach.

It's been done a number of times (the DH MIB proves it's possible and
has been used), but is still not the point...  Bootstrapping USM was
not the issue operators wanted solved.  They didn't want a coupled
or bootstrapable user base, they wanted a single one that wasn't
specific to SNMP.

-----
   From an operational perspective, it is highly desirable to use
   security mechanisms that can unify the administrative security
   management for SNMPv3, command line interfaces (CLIs) and other
   management interfaces.  The use of security services provided by
   lower layers is the approach commonly used for the CLI, and is also
   the approach being proposed for NETCONF [I-D.ietf-netconf-ssh].

   This document describes a Transport Subsystem extension to the
   RFC3411 architecture.

A transition sentence between those 2 paragraphs would be nice.  Maybe
end the second one with:

This document describes a Transport Subsystem extension to the RFC3411
architecture.  This extension specifies how other lower layer
protocols with common security infrastructures can be used underneath
the SNMP protocol and the desired goal of unified administrative
security can be met.

[I just like saying "unified administrative security".]

-----

   +-------------------------------------------------------------------+
   |  SNMP entity                                                      |
   |                                                                   |
   |  +-------------------------------------------------------------+
   |
   ...

That diagram needs an introduction to it.  Like:

The "Transport Subsystem" is defined in RFC3411 as a component of
the SNMP Engine.  The following diagram depicts its place in the
SNMP architecture framework:

-----
   According to [RFC3411], it is not required to protect against denial
   of service or traffic analysis.

Can we change it to: "it is not required to protect against denial of
service or traffic analysis, but it should not make those threats
significantly worse".

-----
   It has been a long-standing requirement that SNMP be able to work
   when the network is unstable, to enable network troubleshooting and
   repair.  The UDP approach has been considered to meet that need well,
   with an assumption that getting small messages through, even if out
   of order, is better than getting no messages through.  There has been
   a long debate about whether UDP actually offers better support than
   TCP when the underlying IP or lower layers are unstable.  There has
   been recent discussion of whether operators actually use SNMP to
   troubleshoot and repair unstable networks.

   There has been discussion of ways SNMP could be extended to better
   support management/monitoring needs when a network is running just
   fine.  Use of a TCP transport, for example, could enable larger
   message sizes and more efficient table retrievals.

These two paragraphs seem out of place?  The text, though interesting
and potentially informative, don't connect with anything else nearby.
I suspect a point needs to be made after them along the lines of:

"This document does not try to argue one way or another about which
protocols are better for use in which situations as there is very
little technical data upon which to draw conclusions from."

-----
   Transport models MUST be able to coexist with other transport models,
   and may be designed to utilize either TCP or UDP or SCTP.

Or any other future protocol layer?

-----
   IETF standards typically require one mandatory to implement solution,
   with the capability of adding new mechanisms in the future.  Part of
   the motivstion of developing transport models is to develop support
   for secure transport protocols, such as a transport model that
   utilizes the Secure Shell protocol.  Any transport model should
   define one minimum-compliance security mechanism, preferably one
   which is already widely used to secure the transport layer
   protocol.

That last sentence is a bit odd.  EG, if the UDP transport document
was written today would it state that USM is the mandatory to
implement security model for use if SNMP/UDP was implemented?  It's
hard to tell what you're getting at here.  Or would the SSH transport,
which you talk about below, specify that SSH is mandatory to
implement?  Or would the SSH transport indicate that a particular
set of auth/priv algs be mandatory?  Not sure which level of
requirement you're talking about ("security mechanism" is vague).

-----
   The RFC3411 architecture,and the USM assume that a security model is
                            ^
                            needs space

-----
					   To accommodate this, the ASIs
   for the transport subsystem, the messaging subsystem, and the
   security subsystem will be extended to pass security-model-
   independent values, and a cache of transport-specific information.

Based on the above text, the following diagram seems out of place.
Add another paragraph stating:

The following diagram depicts the complete SNMPv3 architecture
including the Transport Subsystem defined in this document:

Then the diagram also has "*"s under the MP and Security subsystems.
Not sure why?  They're not talked about.

-----
   3.2.1.1.  USM and the RFC3411 Architecture

   The following diagrams illustrate the difference in the security
                 ^^^^^^^^
   processing done by the USM model and the security processing
   potentially done by a transport model.

there isn't any "following diagrams".  Maybe you mean "lists"
Actually, that paragraph may be long in the 3.2.1 section heading instead?

-----
3.2.1.1 - 3.2.1.3: new lines are needed before the first numbered
bullet in each of these sections.

-----
   A secure transport model will establish an encrypted tunnel between
   the transport models of two SNMP engines.  One transport model
   instance encrypts all messages, and the other transport model
   instance decrypts the messages.

-> "...will establish an authenticated and/or encrypted tunnel between..."
(encryption isn't required)

And the last sentence should be deleted.  It implies unidirectional
and it's not really needed so I'd delete instead of fixing it.

I'd be tempted to use "session" instead of tunnel.  Only because many
people read "tunnel" and think "encryption" (though tunnels can be
authenticating only)

-----
   3.2.2.1.  securityName Binding

   For SNMP access control to function properly, security processing
   must establish a securityModel identifier, a securityLevel, and a
   securityName, which is the security model independent identifier for
   a principal.  The message processing subsystem relies on a security
   model, such as USM, to play a role in security that goes beyond
   protecting the message - it provides a mapping between the USM-
   specific principal to a security-model independent securityName which
   can be used for subsequent processing, such as for access control.

Can we remove USM from that paragraph?  The first is probably fine as
an example, but the second should be replaced with "Security Model".

-----
   For outgoing messages, even when a secure transport model will
   provide the security services, it is necessary to have an security
   model because it is the security model that actually creates the
   message from its component parts.  Whether there are any security
   services provided by the security model for an outgoing message is
   model-dependent.

Shouldn't it be mentioned that care MUST be taken to ensure that a
SNMP engine is sending packets out over a transport using credentials
that are legal for that engine to use on behalf of that user?  I worry
about the case where an engine has multiple transports open and is
"tricked" into sending a message through the wrong transport.

-----

### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### 
   It is important to note that the architecture described in [RFC3411]
   does not include a session selector in the Abstract Service
   Interfaces, and neither is that done for the transport subsystem, so
   an SNMP application cannot select the session except by passing a
   unique combination of transport type, transport address,
   securityName, securityModel, and securityLevel.

PLEASE don't talk about how restricted the architecture is due to the
parameters the ASI have available to them.  The SNMPv3 working group
fought this battle over whether or not to include them and decided
that parameters should be include but are not binding and shouldn't be
treated as an API or a fixed list of things to pass around.  Your
statement above only solidifies the "bad" aspects of the ASIs.
You can continue to provide the list of what an application must
provide to the lower layer systems, but please don't say "so an SNMP
application cannot..." because it can if it treats the ASIs as they
were intended.
### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### 

-----
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
   					      Responses are expected to
   be returned using the same session that carried the corresponding
   request message.  Reuse of sessions is not required for conformance.

Um...  IMHO, this should be a MUST.  There are security implications
if you send a response over a different session than the request came
in over.  Different sessions may use different cryptographic properties
(algorithms, etc).  Plus, once you start doing that you can actually
play with the timing of messages as they arrive at the other end by
slowing one session down and not the other, etc.

This, IMHO, is critical that responses go back on the same session.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 

-----
   		  If each session uses new session keys, then messages
   cannot be replayed from one session to another.

Can you be more specific about what you're trying to say there?    Does
that mean that if I have a GET operation that tries one session and
fails to get a response I have to do what exactly before I'm allowed
to resend it on another session?  is changing the message ID
sufficient?

This is actually a good thing, don't get me wrong, I'm just trying to
understand it.  Cryptographically resending the exact same message in
another session under a different key does provide some extra
comparison information to an attacker.  But the text doesn't really
state the real goals and requirements here.  [though SNMP messages
already suffer from fairly regular bytes that fall into the block size
of the algorithms being used so I'm not sure you're actually
protecting against that much analysis by blocking a resend]

-----
   SNMPv3 was designed to support multiple levels of security,
   selectable on a per-message basis by an SNMP application, because
   there is not much value in using encryption for a Commander Generator
   to poll for non-sensitive performance data on thousands of interfaces
              ^
              ^
              add "potentially"

-----
   4.2.  Command Responder

   This diagram shows how a Command Responder or Notification Receiver
   application registers for handling a pduType, how a PDU is dispatched
   to the application after an SNMP message is received, and how the
   Response is (asynchronously) send back to the network.

Is this the diagram that was changed (4.1 says it was taken from the
other, so I'm assuming it was this one)?  If so then you should state
how it was changed.

-----
   5.2.  tmStateReference

   For each message or transport session, information about the message
   security is stored in a cache, which may inlcude model- and
                                            ^^^^^^^
[I didn't do a spell check and generally don't consider myself worthy
to point out grammar issues, but this jumped out at me :-]

-----
   						      and if state
   information is available when a session is closed, the session state
   information should also be released.

Unless the management system indicates that the state should remain
around for a longer period of time to allow for data collection about
the session to occur.  See David Perkins for details.

-- 
Wes Hardaker
Sparta, Inc.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 10 Jan 2007 18:22:14 -0500

> to resend it on another session?  is changing the message ID

The answer should be "nothing".  I believe what the quoted text is trying 
to say is that if each session uses new keys, then a cross-session replay 
attack will be unsuccessful; that is, an attacker cannot successfully 
replay on one session a message he observed from another session.

A good security protocol (including SSH) will also protect against replay 
attacks _within_ a session; that is, an attacker cannot successfully replay 
a message observed earlier in the same session.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 10 Jan 2007 16:15:32 -0800

>>>>> "JH" == Jeffrey Hutzelman <[email-masked]> writes:

draft> If each session uses new session keys, then messages
draft> cannot be replayed from one session to another.
draft> 

WH> Can you be more specific about what you're trying to say there?    Does
WH> that mean that if I have a GET operation that tries one session and
WH> fails to get a response I have to do what exactly before I'm allowed
WH> to resend it on another session?  is changing the message ID
WH> sufficient?

JH> The answer should be "nothing".  I believe what the quoted text is
JH> trying to say is that if each session uses new keys, then a
JH> cross-session replay attack will be unsuccessful; that is, an attacker
JH> cannot successfully replay on one session a message he observed from
JH> another session.

JH> A good security protocol (including SSH) will also protect against
JH> replay attacks _within_ a session; that is, an attacker cannot
JH> successfully replay a message observed earlier in the same
JH> session.

Ah.  It does make sense in that context.  When reading it I was
implying it was a requirement that the SNMP engine would have to
implement, not a requirement to imposed on a transport.  From a
transport perspective sending a generic message received from above of
any kind, I agree that's a necessary requirement.
-- 
Wes Hardaker
Sparta, Inc.