Re: [Isms] security name relevant text from the current SSH draft andneeded changes

["tom.petch" <cfinss at dial.pipex.com>]

----- Original Message -----
From: "Wes Hardaker" <wjhns1 at hardakers.net>
To: <isms at ietf.org>
Sent: Monday, March 02, 2009 9:14 PM
Subject: [Isms] security name relevant text from the current SSH draft andneeded
changes


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

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.

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

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 at ...)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?
alice+bob at example.com:notifyport
bob+bob at example.com:requestport
alice+bob at example.com:requestport
will generate three separate sessions, but I am assuming that that is the
intended requirement.
>
>
> 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.
>

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

Tom Petch

> Wes Hardaker
> Sparta, Inc.