Re: [Isms] wg last call followup - sshtm

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> On Mon, 02 Mar 2009 13:25:30 -0500, Jeffrey Hutzelman <jhutz at cmu.edu> said:

This is the important part that everyone needs to understand.  I'm sort
of confused why we're rehashing stuff that was long ago discussed and
even agreed upon (I thought by a fairly big majority of the people!).

JH> ... the response will come back _over the same ssh session_.  Period.
JH> We don't get a response back from a particular IP address or hostname
JH> or user.  We get a response back over the channel _we_ opened.  This
JH> is exactly what tmSameSecurity is fore.

Stream based transports like SSH or even DTLS (which is defining a
cryptographic stream, even if it's not a packet based stream like a TCP
stream) performs things in an order:

  1) start up the stream, sharing and negotiating information like
     certificates, names, passwords, options, etc.

     Alice <----  ----> Bob

     The result of this negotiation is almost always some sort of "handle"
     and in most implementations is a file-descriptor socket at the heart
     of it all (IE, an integer number identifying the stream to the
     kernel/what-have-you).

  2) Send traffic through the stream.  It's important to note that pretty
     much every protocol *does not send the user name /etc again*.  It'd
     be highly redundant to keep sending messages saying "oh, and this is
     from Bob again".  The stream user on one side is expected to know
     that already (regardless of whether they initiated or accepted the
     connection).

  3) close the connection upon request


For the SSHTM we just recently added wording (I thought; I have yet to
check the new draft) that basically says that the tmSecurityName needs
to be cached/consistent during the life of a session.  That way when
Alice sends a first message with a securityName of "alice" but that says
"open bob at foo.com" where bob@ is the SshTransportAddress convention,
alice's stack remembers that "alice" is the security name for the
lifetime of the session on our end.  When it gets *any* messages from
the other side, it passes up "alice" as the tmSecurityName in the
upward-bound traveling tmStateReference.


If alice didn't want it this way and actually wanted "bob" to be
securityName, she would have set the initial tmStateRerence's
tmSecurityName correctly.  It'd be *her* fault for not tying them
together.

-- 
Wes Hardaker
Sparta, Inc.