Re: [Isms] secshell-pre14 - transport validation

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

> -----Original Message-----
> From: dave.shield at googlemail.com 
> [mailto:dave.shield at googlemail.com] On Behalf Of Dave Shield
> Sent: Friday, February 06, 2009 6:11 AM
> To: j.schoenwaelder at jacobs-university.de; David Harrington
> Cc: isms at ietf.org
> Subject: Re: [Isms] secshell-pre14 - transport validation
> 
> 2009/1/23 Juergen Schoenwaelder 
> <j.schoenwaelder at jacobs-university.de>:
> > On Thu, Jan 22, 2009 at 03:42:22PM -0500, David Harrington wrote:
> >
> >> This is an updated draft for secshell.
> >
> > Can the WG members please review the changes?
> 
> I've spotted a few (related) issues in section 5.2:
>       Procedures for sending an Outgoing Message.
> 
> 
> 1)  The ASI sendMessage includes two parameters
>      'destTransportDomain' and 'destTransportAddress'.
>     The tmStateReference cache entry includes two fields
>     'tmTransportDomain' and 'tmTransportAddress'
> 
>     The expectation is clearly that these two pairs will have the
>     same value.   What should be the behaviour if they do not?
> 
tmsm states in section 6.1
"How the information in the cache is used is transport-model-dependent
and implementation-dependent.", so the only place where that would be
a consideration is within SSHTM, in which the EOP uses the values of
tmXXXX and ignores the values of destXXX.

> 
> 2)  If the tmSameSecurity flag is set, then tmSessionID is
>      used to look up the appropriate SSH session.
> 
>      What should be the behaviour if the remote end of this
>      connection does not match the specified tmTransportAddress?
> 
the developers should debug their implementation ???

> 
> Clearly, in a well-behaved environment, neither of these should
> occur.  Is it safe to assume that these situations are impossible,
> or should the EoP include some form of validation?

The sessionID is implementation-dependent, so we don't have enough
information about how to validate it.

> 
> 
>   3)  Steps 1) and 2) check and extract tmTransportDomain,
>        but the value is never used (neither here, nor in 5.3)
> 
>        What should be the behaviour if this value is not
>        'snmpSSHDomain' ?
> 
the developers should debug their implementation ???
We should never hit this code if the value of tmTransportDomain
is not snmpSSHDomain. The security model directs processing into SSHTM
code based on tmTransportDomain=snmpSSHDomain. So this would be a
programming error if they do not match.

> 
>   4)  Step 1) checks for the existence of various fields in the
>       tmStateReference cache, but this list does not include
>       tmSessionID.

That is deliberate.

> 
>       What should be the behaviour if this entry is missing
>       from the cache?
>       Does it make a difference whether tmSameSession
>       is set or not?

Yes. For a non-response, the sessionID may not get generated until the
openSession() call in step 4.

> 
> 
> Dave
>