Subject: [Isms] security name relevant text from the current SSH draft and needed changes

From: Wes Hardaker <[email-masked]>
Date: Mon, 02 Mar 2009 12:14:41 -0800

>From the address TC:

         The beginning of the address specification may contain a
         username followed by an '@' (ASCII character 0x40). This
         portion of the address will indicate the user name that should
         be used when authenticating to an SSH server. If missing, the
         SNMP securityName should be used. After the optional user name
         field and '@' character comes the hostname or IP address.

>From the Incoming EOP:

   1.  The SSH Transport Model queries the SSH engine, in an
       implementation-dependent manner, to determine the
       transportAddress, the principal name authenticated by SSH, and a
       session identifier.  The transportAddress must be consistent
       during the life of a SSH session.

       By default on the server side of a SSH connection, the principal
       name is the value of the user name field of the
       SSH_MSG_USERAUTH_REQUEST message for which a
       SSH_MSG_USERAUTH_SUCCESS has been sent.  How this name is
       extracted from the SSH environment is implementation-dependent.

   2.  Create a tmStateReference cache for subsequent reference to the
       information.

          [...]

          tmSecurityName = the ssh principal name received by the SSH
          server or sent from a SSH client.

          [...]

So, after reading this it does look like something is wrong here and
could be interpreted incorrectly from what I believe we all agreed upon.
Most of this is related to the "or" clause in that last sentence.

I believe the final tmSecurityName line should read (there may be other
text that needs to change too, but this is the important one):

          tmSecurityName = the tmSecurityName associated with the
          session, if the session was previously established, or the ssh
          principal name received by the SSH server for new incoming
          connections.

In short when receiving a message, the processing should be:

  Is this a new incoming connection?

      Yes: set the tmSecurityName to the SSH user name and cache it for
           future use for the "No" case (*) below.

    No(*): set this to the cached tmSecurityName

For outgoing messages:

  Cache the tmSecurityName pulled from the tmStateReference for use when
  replies come back from the session in (*) above.  At no point will the
  Yes clause above be triggered if we're opening the connection.

  Disallow all future outgoing messages for this session (identified by
  the tmSessionID) to use a tmSecurityName other than the cached one.

I think this logic should meet what everyone is expecting, based on
previously agreed upon consensus.  If the above looks good logic wise,
I'll even offer to check what text needs to be modified and submit a
fast proposal for fixing it.  Note that the ID cut-off for a -15 is
imminent.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "tom.petch" <[email-masked]>
Date: Tue, 3 Mar 2009 15:08:00 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 02, 2009 9:14 PM
Subject: [Isms] security name relevant text from the current SSH draft andneeded
changes

>          field and '@' character comes the hostname or IP address.

In passing, I think it wrong to have to read the TC to find how the EOP works.
Hence the indignation in my first message over the first piece of text that a
user of isms will find that refers to e-mail format addresses.  That text must
come at least as early as s.3 of ssstm; but I think tmsm is the really right
place.

>           connections

We have not got a cache!!!  We started many years ago with a session cache, but
the EOPs have forced that into a message cache; which it has to be else mappings
get lost.  Note that the EOPs rightly call for a new one to be created for each
inbound message.

So now we need to reinvent the session cache.  And we need to be very careful
about how we identify entries since we took several years to get that right with
the message cache.  Forget servers and CRs, the problem is CG.

When the first Request message crosses the API into sshtm, we check using
securityName and transportAddress.  That is all we have.  When ssh successfully
opens a session, we have a tmSessionID (we need text added to s.3 about this).
I say that securityName+transportAddress (alice+bob@...)uniquely identify a
session, ditto tmSessionID and the relationship MUST be one to one.  Then sshtm
checks for the absence of an entry in the cache, creates one; ssh then generates
tmSessionID which it or more likely sshtm inserts into the cache (I find the
current text on tmSessionID unclear).

For inbound Responses, ssh identifes the session to sshtm by tmSessionID
and sshtm can then extract the securityName and pass it up the stack as
tmSecurityName

Consequence?
[email-masked]:notifyport
[email-masked]:requestport
[email-masked]:requestport
will generate three separate sessions, but I am assuming that that is the
intended requirement.
> fast proposal for fixing it.  Note that the ID cut-off for a -15 is

Please no, forget the cutoff, let's get this right.

Tom Petch