Subject: [Isms] isms-tmsm-12 comments

From: Wes Hardaker <[email-masked]>
Date: Thu, 17 Jul 2008 16:52:25 -0700

General comments:

* I think the document is very well written and should go
  forth ASAP.

* The document sort of tries to be a generic transport document (as even
  the title implies) but really reads as if it applies specifically to
  security related transports.  I don't think this is a problem, per
  say, but at one point I thought the goal was to document the
  definition of what a transport should take regardless of its security
  properties.  A lot of the document discusses things in a security
  transport specific way.  Not worth changing anything, IMHO, though.

* I evaluated it thinking about it in terms of the SNMP/DTLS draft I
  recently published to see if both that draft and this one worked well
  together, and I'm happy to say it does and if anything, this document
  made me write down some notes to check about needed statements in the
  DTLS document!

Section 1.2, first paragraph after the diagram:

   OLD:
   The transport mappings defined in RFC3417 do not provide lower-layer
   security functionality, and thus do not provide transport-specific
   security parameters.  This document updates RFC3411 and RFC3417 by
   defining an architectural extension and ASIs that transport mappings
   (models) can use to pass transport-specific security parameters to
   other subsystems, including transport-specific security parameters
   translated into transport-independent securityName and securityLevel
   parameters

   NEW:

   The transport mappings defined in RFC3417 do not provide lower-layer
   security functionality, and thus do not provide transport-specific
   security parameters.  This document updates RFC3411 and RFC3417 by
   defining an architectural extension and ***modifies the*** ASIs that
   transport mappings ***DELETE:(models)*** can use to pass
   transport-specific security parameters to other subsystems, including
   transport-specific security parameters ***that are*** translated into
   ***the*** transport-independent securityName and securityLevel
   parameters

   I'd stick with just "mappings" or "models" for statements like that
   to reduce terminology confusion.  Having both sounds kind of
   confusing.  (And the problem is that the older "mappings" would
   technically be defined as new "models").

Section 2, last sentence:

  * Delete "(or models)"

  I think it only adds confusion

Section 1.3, second paragraph:

  * One thought would be using Must, Should and May to indicate RFC34111
    compatibility.

Section 2, 4th paragraph last sentence:

   OLD:

         The more important issue is that operators wanted to leverage a
   single user base that wasn't specific to SNMP.

   NEW:

         The more important issue is that operators wanted to leverage
   ***existing user base infrastructures that weren't*** specific to SNMP.

   rational: I don't think they necessarily wanted a single user base;
   they wanted their user base.  EG, If you offered them a method to use
   USM logins on their systems in order to provide a single login
   database, I don't think they'd be happy even though they were
   provided a single database to maintain.

Section 2, paragraph 7, last sentence:

  OLD:

                           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 [RFC4741].

  NEW:

                           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 ***other network management protocols***
   NETCONF [RFC4741].

Section 3.1.1, 3rd P, first sentence:

   OLD:

   A Transport Model SHOULD require no modifications to the underlying

   NEW:

   A Transport Model SHOULD NOT require modifications to the underlying

Section 3.2.1, 2nd P, last sentence:

   OLD:
                                                        As work is being
   done to expand the transport to include secure transport such as SSH
   and TLS, using a subsystem will enable consistent design and
   modularity of such Transport Models.

   NEW:
                                                        As work is being
   done to expand the transport***s*** to include secure transport***s***...

Section 3.2.1.1, title:

   OLD:
   3.2.1.1.  Processing Differences between USM and Secure Transport

   NEW:
   3.2.1.1.  Processing Differences between USM and Secure Transport***s***

Section 3.3.1, 2nd P, last sencence:

   OLD:
                                     If the Transport Model cannot
   provide at least the requested level of security, the Transport Model
   SHOULD discard the message and notify the dispatcher that
   establishing a session and sending the message failed.

   NEW:
                                     If the Transport Model cannot
   provide at least the requested level of security, the Transport Model
   SHOULD discard the message and ***SHOULD*** notify the dispatcher that
   establishing a session and sending the message failed.

   Desire: separate the two different statements in that sentence and
   put SHOULDs on each.

Section 3.3.1, 3rd P:

   "notify ." => "notify."   (note the extra space)

Section 3.3.1, 3rd P, last sentence:

   OLD:
               If a session cannot be established then the message is
   discarded and the dispatcher should be notified that sending the
   message failed.

   NEW:
               If a session cannot be established then the message is
   discarded and the dispatcher ***SHOULD*** be notified that sending the
   message failed.

Section 3.3.2, 2nd P:

   This paragraph comes close to contradicting itself.  It says that
   it's not recommended to base session length on an operations (IE,
   don't try to predict operations) and then says that predicting how to
   define an operation is implementation-dependent.  I don't think the
   last sentence is needed, given the point behind the second.  I
   suggest dropping the last one.

Section 3.3.3, first P:

   OLD:
   A Transport Model session is associated with state information that
   is maintained for its lifetime.  This state information allows for
   the application of various security services to multiple messages.
   Cryptographic keys associated with the transport session SHOULD be
   used to provide authentication, integrity checking, and encryption
   services, as needed, for data that is communicated during the
   session.  The cryptographic protocols used to establish keys for a

   NEW: A Transport Model session is associated with state information
   that is maintained for its lifetime.  This state information allows
   for the application of various security services to ***protect***
   multiple messages.  Cryptographic keys associated with ***a secure***
   transport session SHOULD be used to provide authentication, integrity
   checking, and encryption services, as needed, for data that is
   communicated during the session.  The cryptographic protocols used to
   establish keys for a

Section 3.3.3, first P:

   Remove the _'s surrounding _within_ in the last sentence

Section 3.3.3, 2nd P:

   OLD:
   A Transport Model session will have a single transportDomain,
   transportAddress, securityName and securityLevel associated with it.
   If an exchange between communicating engines requires a different
   securityLevel or is on behalf of a different securityName, then
   another session would be needed.  An immediate consequence of this is
   that implementations SHOULD be able to maintain some reasonable
   number of concurrent sessions.  ***Note that other transport sessions
   with identical values may exist.  These four attributes do not
   imply a key that can be used to uniquely identify a session***

   ADD to the end:

   ***Note that other transport sessions with identical values may
   exist.  These four attributes do not imply a key that can be used to
   uniquely identify a session***

Section 3.3.3, last P:

   OLD:
                                            A Transport Model may
   upgrade the requested security level, i.e. noAuthNoPriv and
   authNoPriv MAY be sent over an authenticated and encrypted session.

   NEW:
                                            A Transport Model ***MAY***
   upgrade the requested security level, i.e. noAuthNoPriv and
   authNoPriv ***may*** be sent over an authenticated and encrypted session.

   (the MAY is on the example, not the requirement text)

Section 5.2, 1st P:

   OLD:
   stored in a cache to pass model- and mechanism-specific parameters.

   NEW:
   stored in a cache to pass model-***specific*** and mechanism-specific
   parameters.

   Obviously a nit pick for personal preference...

Section 6.1, 2nd P:

   OLD:
   In the diagram in section 4.6.1 of RFC 3411, the sendMessage ASI
   replaces the text "Send SNMP Request Message to Network".  In section
   4.6.2, the sendMessage ASI replaces the text "Send SNMP Message to
   Network"

   NEW:
   In the diagram in section 4.6.1 of RFC 3411, ***this document's***
   sendMessage ASI replaces the text "Send SNMP Request Message to
   Network".  In section 4.6.2, ***this document's*** sendMessage ASI
   replaces the text "Send SNMP Message to Network"

Section 6.2:

   Comment: it's a bit odd that the only two not shown were the
   generateRequestMsg and generateResponseMsg...  Why not just show them?

Section 6.3:

   OLD:
   In the diagram in section 4.6.1 of RFC 3411, the receiveMessage ASI
   replaces the text "Receive SNMP Response Message from Network".  In
   section 4.6.2, the receiveMessage ASI replaces the text "Receive SNMP
   Message from Network"

   NEW:
   In the diagram in section 4.6.1 of RFC 3411, ***this document's***
   receiveMessage ASI replaces the text "Receive SNMP Response Message
   from Network".  In section 4.6.2, ***this document's***
   receiveMessage ASI replaces the text "Receive SNMP Message from
   Network"

Section 7:

   One thing that worries me is the following: say an application
   specifies a security model of TSM (with authPriv requirements) but
   messes up and specifies a transport domain/address of a normal
   UDP/IPv6 address pairing.  The UDP/IPv6 address transport won't
   successfully decline sending the message because it doesn't meet the
   criteria.  Note that I haven't checked to see if this is discussed in
   the TSM document, but maybe it should be mentioned in this one?  This
   isn't an attack vector, mind you, but does allow an administrator to
   accidentally send a potentially sensitive and unencrypted packet in
   the clear.  The other side will drop it, since the TSM will check the
   received securityLevel (that much I remember).

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