Top-posting makes it really hard to understand what you are
replying to.
(sorry. I intended a really short reply.)
As I understand it, the request and response don't carry
tmSecurityName,
which is information passed between the TM and the upper layers.
The
request carries a securityName, and if that is "alice" then the
securityName in the response should also be "alice".
If a request is sent with securityName="alice" via an SSH
transport using
transport address "ahopkins at router1.example.net:1234", then
what happens
next depends on whether tsm or some other security model is
used. At the
receiver, tmSecurityName is going to be "ahopkins", derived
from the SSH
user name. If the security model in use is TSM, then TSM is
going to look
at that value, compare it to the securityName in the message,
I think there is no securityName in the message.
Per TSM 4.2 3)
3) Set securityParameters to a zero-length OCTET STRING ('0400').
and reject
the request because they do not match.
Per rfc3412, matching is done by message processing models, in the
prepareDataElements EOP. prepareDataElements takes only a
transportDomain, transportAddress, a wholeMsg and a message length as
input. It returns the sendPDUHandle that identifies the matching
request, which is used to direct the response to the appropriate
application.
The user@ feature is an SSHTM-specific feature, not a TSM feature. I
think SSHTM needs to pass a transportAddress for the response that
will match the one used in the request. This is symmetrical - it is
the SSHTM that takes the requested ahopkins at ... transportAddress and
splits it into an address and a user name. SSHTM should put
"ahopkins@" and the address back together into a corresponding
transportAddress. Then the appropriate MPM can find the sendPDUHandle.
tmSecurityName is set to "alice" by TSM. SSHTM is the place where the
requested tmSecurityName "alice" is overridden, and ahopkins is chosen
as the user name. For an incoming response, SSHTM should determine
that the matching tmSecurityName for the response should be "alice",
not "ahopkins". This would seem to require an internal mapping table
that keeps track of all the alice-to-"ahopkins@" conversions done
going outward, and back-converting them on the way in. This might
require some type of transport-mapping-specific sendPDUHandle for
matching specific requests and responses.
