Re: [Isms] wg last call followup - sshtm

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

Wes

You probably have the text in sshtm s.5.2 4) 2) in mind which, unlike this
e-mail, makes no mention of caching the tmSecurityName. Hence the problem. alice
is not recorded anywhere and so cannot be presented to the application with the
Response message.

Tom Petch


----- Original Message -----
From: "Wes Hardaker" <wjhns1 at hardakers.net>
To: "Jeffrey Hutzelman" <jhutz at cmu.edu>
Cc: "David Harrington" <ietfdbh at comcast.net>; "'tom.petch'"
<cfinss at dial.pipex.com>; "'Juergen Schoenwaelder'"
<j.schoenwaelder at jacobs-university.de>; <isms at ietf.org>
Sent: Monday, March 02, 2009 8:48 PM
Subject: Re: wg last call followup - sshtm


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