Re: [Isms] TBD secshell
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] TBD secshell
> 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.
dbh
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.