Subject: [Isms] Notes on an SSH Document Review

From: Wes Hardaker <[email-masked]>
Date: Fri, 29 Aug 2008 09:24:28 -0700

Here are some notes about the SSH document as I've reviewed it.  It's
divided into pieces, with the technical issues first to separate them
from the simple wording edits that I thought were needed.

+ General Comments
  - This is also another extremely well written document and
    my hats off to the editors for doing such a good job in
    documenting everything that is needed.
+ Technical Issues
  - Section 3.1.2, paragraph startingc "The SSH Transport Model"
    * I'm not sure of the reasoning behind such strong
      wording to say that transport level protections
      offered to the packets "SHOULD NOT be exposed to the
      SSH Transport Model".  I'm not sure how this helps
      interoperability and I think some implementations may
      benefit from exposing that detail so they could
      provide a configuration system at the TM level.  I
      think MAY NOT would be more appropriate.
  - Section 3.1.3, DISCUSS in 2nd paragraph
    * The question is: is this paragraph needed.  I don't
      think it is.  I think it's beyond scope to discuss the
      details of how SSH needs to do it's authentication.  The
      first paragraph nicely states that we're relying on SSH
      authentication and the next 2 are really just examples
      of stuff that may or may not be used.  That being said,
      I don't mind if it stays either.  But to answer the
      DISCUSS: no I don't think it's needed.
  - Section 3.1.4: DISCUSS
    * I don't think we need to go into gory detail here
      either.  But *if* the gory detail is left in 3.1.3, then
      it's probably appropriate to add similar stuff here.
      Maybe one sentence of:
      + "The SSHTM expects that SSH is appropriately
        configured with currently acceptable encryption
        algorithms to support privacy levels needed to protect
        SNMPv3/SSHTM traffic."
  - Section 3.1.6: Subsystem naming
    * I have two concern over subsystem naming
      1. I think there could very well be real world
         user-configuration out there today that has "snmp" as
         a configured subsystem.  I'd suggest we pick a less
         likely to conflict name here.  Either "snmpv3" or
         "isms" comes to mind as less likely to be used in the
         real world.
      2. Re: DISCUSS: I do think we need two different
         subsystem names though.  For management stations that
         are running an agent, it's highly likely that they
         are also running a notification receiver and the ssh
         subsystem destination shouldn't be the same.  If we
         end up assigning SNMP-over-SSH specific ports for
         these services, then the susbsystem name really
         doesn't matter.  If, however, we end up reusing 22 we
         certainly need one ssh subsystem name for an agent
         ("commandresponder") and another for notifications
         ("notificationreceiver").  I doubt either of those
         two are in use today!
    * Note: IANA considerations needs to change too
    * Note: Step 7 of 5.3 would need to be changed too.  If
      nothing else, spelling out the exact subsystem name to
      use there would be good even if it doesn't change.
  - Uniquely Identifying Sessions
    * I don't think that the quadruple of addrType, Addr,
      securityName and securityLevel serve as a good unique
      identifier combination.  At least section 3.1.6
      specifies this as "unique".  It's certainly the case
      that the architecture may require this because the
      architecture doesn't have session pointers to pass
      around.  But I think that most real-world
      implementations may support more than one connection
      with identical values for these 4 variables.  I've
      certainly seen some that (if modified to support SSH)
      will end up with non-unique combinations.  This isn't a
      problem for the implementation as they're already
      passing around other references.  So there are two
      things here that fall out of this:
      + Should the text be modified to add "implementations
        MAY have an alternative implementation-dependent
        method of identifying SSHTM sessions"
        
    * Section 5.4: the closeSession() ASI won't actually work
      for similar stacks and only offers two identifiers for
      uniqueness when pointing at a session to close.
    * Section 7, sshtmLCDTable
      + If the table is kept (see list discussion) then I don't
        think the indexes are sufficiently unique for real-world
        implementations (see above).
  - Section 4.2: tmSecurityName
    * I'm not sure how pulling the SSH identity from the SSH
      layer is implementation dependent.  If two different
      implementations are expecting it to be pulled from two
      different portions of the packet then they won't
      interoperate at all!  Now, in reality I think they'll
      likely pick the same field.  But "by default,
      tmSecurityName is determined from the value of the
      user name field of the SSH_MSG_USERAUTH_REQUEST
      message" isn't wise interoperable wording.  I'd say it
      *is* determined from that or else implementations that
      pick otherwise won't interoperate.
+ Wording Edits
  - Section 3.1.1, steps 1 and 2
    * The wording for bullets 1 and 2 and close together and
      somewhat confusing.  I'd suggest:
      1. Message Stream Modification - SSH provides for
         verification that messages sent have not been
         dropped or reordered during its transmission through
         the network.
      2. Information Modification - SSH provides for
         verification that the contents of each received
         message has not been modified.  Data within a message
         can not be altered without it being detected by SSH.
    * I'm not sure it's worth including "to an extent greater
      than can occur non-maliciously" since the application
      (the SNMPv3 stack in this case) won't see any
      modifications and in the worst case SSH would cause the
      session to terminate...  It won't know if it's malicious
      or not.
  - Section 3.1.1, steps 3 and 4
    * Steps 3 and 4 are also closely related and I'd either
      combine them or separate them into "client" and
      "server".  (note that 3411's definiton actually lists
      masquerading as protecting the server from clients, but
      I'd argue both are very important).  How about:
      3.  Server Masquerading - SSH provides verification of
          the identity of the SSH server through the SSH
          Transport Protocol server authentication [RFC4253].
      
      4.  Client Masquerading - SSH provides for verification
          of the identity of the SSH server.  Verification of
          principal identity is important for use with the
          SNMP access control subsystem, to ensure that only
          authorized principals have access to potentially
          sensitive data.  The SSH user identity is provided
          to the transport model, so it can be used to map to
          an SNMP model-independent securityName for use with
          SNMP access control and notification configuration.
          (The identity may undergo various transforms before
          it maps to the securityName.)
  - Section 3.1.2, paragraph starting "The SSH Transport Model"
    * Add a period after "were met" about in the middle of
      the paragraph.
  - Section 3.1.3 first paragraph; minor wording suggestion:
    * OLD: This includes the three authentication methods
      described in the SSH Authentication Protocol document
      [RFC4252] - publickey, password, and host-based - and
      keyboard interactive and others.
    * NEW: This includes the three authentication methods
      described in the SSH Authentication Protocol document
      [RFC4252] (publickey, password, and host-based) and
      keyboard interactive *as well as* others.
  - Section 3.3, first sentence:
    * What's the reason for limiting what types of
      applications can open a connection?  If SNMPv3 is
      extended in the future, they'll likely be able to open
      connections too...  That being said, if you want to
      leave it you need to at least add "proxy forwards" to
      the list of SNMPv3 application types that may open an
      SSH connections.
  - Section 4.2, 4th paragraph
    * tran*b*sform transform
  - Section 4.2 5th paragraph
    * I think using Layer 8 is funny, but I don't think it's
      probably the right wording for the document.  How about
      "intelligent being".
    * I'm not even sure what the benefit to this paragraph is
      within the document.  There is almost nothing in it that
      is SSH specific and it reads more like generic wording
      for the TM document.
  - Section 4.3, first paragraph
    * OLD: "at least architecturally, ..."
    * NEW: "at least in the defined SNMPv3 architecture, ..."
  - Section 5.2 maybe renumber bullets to help the "if" statements.
    * I'd be tempted to renumber the bullet numbers to help the
      if/then statements appear in a better decision tree
      using 2a instead of 3, eg.   It actually looks like a
      bit of work with rewording as well.  If you think it's
      fine as is, then leave it.  If you think I might be
      right, then I'll write something up (let me know). 
  - Section 5.3, second paragraph after openSession ASI
    * "This will" => "This may"
    * add to the end of the sentence: "assuming sufficient
      configuration exists to set up a connection".
  - Section 5.4, first paragraph after closeSession ASI:
    * extra space after "a client and server" before the "."
  - Section 5.4, steps
    * steps are 1, 3 and 4.  Renumber because 2 is MIA
    * Step 4: why is sshtmLCDPrincipal extracted?  I'd suggest
      removing it from the extraction list as it's unneeded.
  - Section 6.3, other MIBs
    * Add the TARGET-MIB?
  - Section 7, MIB, Co-editors
    * Extra spacing not needed between Josephy's company and address.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 Aug 2008 13:35:08 -0400

--On Friday, August 29, 2008 09:24:28 AM -0700 Wes Hardaker 
<[email-masked]> wrote:

\>   - Section 3.1.2, paragraph startingc "The SSH Transport Model"
>       think MAY NOT would be more appropriate.

I don't object to your intent, but I think the phrase MAY NOT should be 
avoided at all costs.  It is logically equivalent to MAY, but many people 
will read it as meaning the same thing as MUST NOT.  Let's just rewrite 
"SHOULD NOT be" as "are not" or even "normally are not".  In any case, I 
think the purpose of this text is not so much to promote interoperability 
but to prevent people down the line from second-guessing our decision to 
leave the details of SSH to SSH and not get SNMP involved in them.

>       DISCUSS: no I don't think it's needed.

Agree.  These paragraphs don't need to be here.

>       either.

I don't think we need this section at all.  The SSH TM doesn't support or 
not support any particular SSH encryption or integrity methods.  SSH 
supports what it supports, and SSHTM supports SSH.  This is equivalent to 
an application that runs over TCP saying it supports PMTU discovery, slow 
start, fast recovery, and so on.  Those things are transparent to anything 
that runs above the layer boundary.

I'm almost inclined to say the same thing about section 3.1.3, but not 
quite.  The difference is that authentication methods _are_ visible above 
the layer boundary, because you have to provide credentials.  And so, the 
set of authentication methods that can be used with SSHTM is limited by the 
kinds of credentials it can provide.

>          ("notificationreceiver").  I doubt either of those

I'm not convinced we need separate subsystem names, but I also don't see 
any harm in having them.  But, let's remember that the namespace is 
universal and not specific to the context of SNMP.  "snmp-commandresponder" 
or even "snmp-command" is a fine subsystem name; "commandresponder" is too 
vague.

>         method of identifying SSHTM sessions"

I'm pretty sure we've been over this elsewhere, and that in fact sessions 
are uniquely identified by being distinct sessions, and not by looking up 
some combination of parameters in a table.  If you get two sessions, they 
have different handles or file descriptors or whatever, and for the purpose 
of directing outgoing responses (which AFAIK is the only reason we need to 
"identify" sessions), you need to remember which one you use.  We even 
provided a means for this, in the form of tmStateReference.

>       uniqueness when pointing at a session to close.

Why do we need this at all?  Isn't session management the TM's job?

>       interoperate at all!

No, it's not about pulling things from the packet.  You don't even get to 
_think_ about ssh packets.  But the means by which an SSH server passes 
username information to a subsystem is not specified; it is specific to the 
SSH implementation.

> But "by default,
>       message" isn't wise interoperable wording.

To my mind, any reference in this document to SSH_MSG_* indicates a 
layering violation.  The details of the operation of the SSH protocol are 
below the abstraction level at which SSHTM gets to interface with SSH. 
Again, this is like talking about the details of TCP packets, payload 
lengths, etc.

> I'd say it

Of course it's determined from that.  SSH says so.  It's not up to us.

-- Jeff