Subject: RE: [Isms] tmsm comments

From: "David Harrington" <[email-masked]>
Date: Thu, 1 Feb 2007 19:46:11 -0500

Hi,

Working on the next revision. Comments inline.

dbh  

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Tuesday, January 09, 2007 1:18 AM
> To: [email-masked]
> Subject: [Isms] tmsm comments
> 
> 
> 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.

Does this cover it adequately?
"USM was designed to be independent of other existing security
      infrastructures. USM therefore requires a separate principal and
key
      management infrastructure. Operators have reported that
deploying
      another principal and key management infrastructure in order to
use
      SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use

      external mechanisms to handle the distribution of keys for
      use by USM. The more important issue is that operators wanted 
      to leverage a single user base 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".]

Done.
> -----
+-------------------------------------------------------------------+
>    |  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:

done
> 
> 
> 
> 
> 
> -----
>    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".
> 
Done.

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

I think removing the two paragraphs would be the best approach.

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

I removed the second part of the sentence, since it doesn't seem
relevant after removing the two preceding paragraphs.

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

This is about having a mandatory-to-implement security mechanism for
the transport model, e.g. certificates, to ensure a basic level of
interoperability.

If SNMP/UDP I streated as a transport model, then USM would be the
mandatory-to-implement security mechanism.

Suggested text welcome. I think the text should talk about algorithm
agility and a mandatory-to-implement for interoperability. I modified
the text somewhat, but would welcome other suggested text. Here's my
attempt:
"IETF standards typically require one mandatory to implement
          solution, with the capability of adding new mechanisms in
the
          future. Part of the motivation 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,
such as 
          certificates, to ensure a basic level of interoperability,
but 
          should also be able to 
          support additional existing and new mechanisms."

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

Artifacts from RFC3411. Removed.
> 
> 
> 
> 
> 
> -----
>    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?

Changed and moved
> 
> 
> 
> 
> -----
> 3.2.1.1 - 3.2.1.3: new lines are needed before the first numbered
> bullet in each of these sections.
> 
I will investigate whether xml2rfc allows me to do this.

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

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

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

I tend to envision this as a type of "pipe"; I think tunnel is
consistent with a pipe; session is not. I'll leave this as is until we
have consensus to change the wording. Suggested text welcome.

> 
> 
> 
> 
> 
> 
> -----
>    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".
> 
Done.
> 
> 
> 
> 
> -----
>    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.
> ### ### ### ### ### ### ### ### ### ### ### ### ### ### ### 
> ### ### ### 

I understand and agree with your concern. I am not sure how to modify
the wording to meet your request. This is after all an architecture
extension document, so we cannot just say ignore the ASIs. Would the
following suffice?

"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 has no mechanism
to select a session
        using the ASIs except by passing a unique combination of
transport type, transport
        address, securityName, securityModel, and securityLevel.
Implementers, of course,
        might provide non-standard mechanisms to select sessions."
> 
> 
> 
> 
> 
> -----
> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
> *** *** *** 
>    					      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.
> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
> *** *** *** 
> 
I have had feedback from others that they do not want this restriction
at the subsystem level, but at the model level. I think it makes sense
to use the same session for both security and complexity reasons. I
think we need to establish WG consensus on this point.

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

Copied text from Jeff's response to your question.
> 
> 
> 
> -----
>    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"

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

These two diagrams are unchanged from RFC3411. I do not have new
scenario diagrams. I am not certain new scenario diagrams would be
useful here because the path back from Security Model through
Messgaing Model through the dispatcher to the transport subsystem's
sendMessage() ASI adds  a lot of empty lines that don't show much of
anything, but complicate the diagram.
 
> 
> 
> 
> 
> 
> 
> 
> -----
>    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 :-]

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

I can understand the desire to have session info last longer than the
session, but the state info (in the LCD) is used to determine if a
session exists, so keeping it around in the LCD might be problematic,
unless it is somehow marked as expired. Since we are not writing a MIB
to represent this, I am not sure how we want to address the
implications of this issue here.

Text welcome.
> 
> 
> 
> 
> 
> 
> 
> -- 
> Wes Hardaker
> Sparta, Inc.
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

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