Subject: Re: [Isms] secshell-pre14 - transport validation

From: Dave Shield <[email-masked]>
Date: Fri, 6 Feb 2009 11:10:53 +0000

2009/1/23 Juergen Schoenwaelder <[email-masked]>:
> 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?

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?

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?

  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' ?

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

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

Dave

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Feb 2009 19:37:20 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Shield
> Sent: Friday, February 06, 2009 6:11 AM
> To: [email-masked]; David Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] secshell-pre14 - transport validation
> 
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.

>      connection does not match the specified tmTransportAddress?
the developers should debug their implementation ???

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

>        What should be the behaviour if this value is not
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.

>       tmStateReference cache, but this list does not include

That is deliberate.

>       Does it make a difference whether tmSameSession

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