Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5

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

Hi,

By all means, please double check my logic on this ...

comments inline. 

> > The one thing that's still slightly unclear is how
tmStateReference
> > cache entry gets created on SSH client side (e.g. command 
> originator).
[...]
> 
> In the expected case, it comes from TSM, in paragraph 4.2(2) of 
> draft-ietf-isms-transport-security-model-10.txt.
> 
> However, modularity demands that SSHTM work even when not 
> used with TSM, 
> and particularly, section 6.1 of draft-ietf-isms-tmsm-15.txt 
> implies that 
> the sendMessage ASI needs to work even when tmStateReference 
> is not given.

I do not believe that is true.
The first step in secshell 5.1 verifies there is a valid
tmStateReference cache. If not, processing stops.

The sendMessage ASI is architectural, but the processing is (and must
be) transport-model specific. The plain-old UDP "transport model"
ignores the cache, and does a simple "Send SNMP Request Message to
Network". When we update RFC3417, we will presumably want to add
elements of procedure for the sendMessage ASI to replace "Send SNMP
Request Message to Network".

The TMSM does not specify that TSM must be used, but section 5.2 does
say that "For architectural modularity between Transport Models and
transport-aware Security Models, a fully-defined tmState MUST
conceptually include at least the following fields:"

and 6.1 says
   If present and valid, the tmStateReference refers to a cache
   containing transport-model-specific parameters for the transport
and
   transport security.  How a tmStateReference is determined to be
   present and valid is implementation-dependent.  How the information
   in the cache is used is transport-model-dependent and
implementation-
   dependent.

> 
> > My guess is that Section 5.2 should say that if tmStateReference
is
> > not present, steps 1..3 are skipped, and instead we create a
> > tmStateReference cache entry (because we can't call openSession
> > without having one) and go to step 4 (opening a new session).

I don't think SSHTM should ever reach step 4 without a
tmStateReference.
SSHTM is not designed to work with a security model that does not
provide a tmStateReference. It would not be secure to do so.

> 
> We don't need a tmStateReference cache entry to call openSession.  

The way it is currently defined you do, and I believe that is the
correct approach. On the way in, it is the responsibility to take
tmSecurityName and determine how to translate that into the
approrpiate securityname for subsequent processing. The same is true
going outbound - the security model should be decidiing which
tmSecurityname should be getting used. It MAY be the same as the
securityName passed in the ASIs, but it also MAY be different. We
cannot make the assumption that they are the same. Creating a
tmStateFerence cache using the securityName form the ASI makes that
assumption. 

SSHTM should not generate an outgoing message without a valid
tmStateReference provided by a security model.

> I 
> believe the right behavior here is in fact to skip directly 
> to step 4, as 
> if there had been no LCD entry, and create a new SSH session.  The 
> difficulty is that currently we can't call openSession without a 
> tmSecurityName, and we don't have one.  I see two possible 
> solutions to 
> this problem:
> 
> (1) redefine openSession (a private ASI between SSHTM and SSH) to
not 
> require a tmSecurityName.  In the case where 
> destTransportAddress does not 
> contain an '@' and tmSecurityName is not given, openSession 
> should not pass 
> any username to SSH.  Instead, SSH will figure out on its own 
> what username 
> to use.  Most SSH client implementations have heuristics for 
> this which are 
> quite often right; in the case of SSHTM-without-TSM, I'd expect
these 
> heuristics to be at least as good as anything else we can do, 
> probably 
> including using the SNMP securityName.
> 
> (2) redefine sendMessage to include the security model, name, 
> and level, so 
> that a secure transport can use them in setting up a session. 
>  Then, if 
> there is no tmStateReference, pass the securityName parameter on to 
> openSession.
> 
> 
> 
> Separately, I think we may have an issue in that sendMessage 
> currently 
> looks for the one-and-only existing session which matches 
> destTransportAddress and tmSecurityName, and then reports an error
if 
> tmSameSecurity is true and the session ID does not match.  Is 
> it possible 
> that there will be two different sessions with the same 
> transport address 
> and security ID? 
>  If so, and even if not, it seems that it may be 
> appropriate to search for the one-and-only existing session 
> with the same 
> sessionID, and then verify that the transport address and 
> security name 
> match, rather than the other way around.


The Elements of Procedure in pre14* revisions check for the sessionID
match first, then for the tmTransportAddress and tmSecurityName match.

   3.  If tmSameSecurity is true and there is no existing session with
       the same sessionID as tmSessionID, then increment the
       sshtmSessionNoAvailableSessions counter, discard the message
and
       return the error indication in the statusInformation.
Processing
       of this message stops.

   4.  If there is no existing session corresponding to the
       tmTransportAddress and tmSecurityName, then call openSession()
       with the tmStateReference as a parameter.
> 
> -- Jeff
>