Re: [Isms] wg last call followup - sshtm

["David Harrington" <ietfdbh at comcast.net>]

Hi,

Actually, I think it is incorrect to say that no mention is made of
caching the tmSecurityName. 

The openSession takes a tmStateReference that already contains a
tmSecurityName, and openSession adds the corresponding tmSessionID to
the tmStateReference cache. This binds the tmTransportAddress and the
tmSecurityName and the tmSessionID together.

When a response is received, it will be received over the existing
session. And by looking up the tmSessionID, we find both the
corresponding tmSecurityName and the correspnding "user@"
transportAddress to pass up the stack. 

Apparently you didn't find that obvious ;-) 

We'll try to make it more obvious.

> -----Original Message-----
> From: tom.petch [mailto:cfinss at dial.pipex.com] 
> Sent: Tuesday, March 03, 2009 9:05 AM
> To: Wes Hardaker; Jeffrey Hutzelman
> Cc: David Harrington; 'Juergen Schoenwaelder'; isms at ietf.org
> Subject: Re: wg last call followup - sshtm
> 
> 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.
> 
>