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

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

I'll look into this.

dbh 

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz at cmu.edu] 
> Sent: Thursday, February 19, 2009 2:14 PM
> To: Pasi.Eronen at nokia.com; ietfdbh at comcast.net; isms at ietf.org
> Cc: jhutz at cmu.edu
> Subject: Re: [Isms] Comments about 
> draft-ietf-isms-secshell-13, Section 5
> 
> --On Thursday, February 19, 2009 09:03:58 AM +0100 
> Pasi.Eronen at nokia.com 
> wrote:
> 
> > David Harrington wrote:
> >>
> >> Hi Pasi,
> >>
> >> Iam not certain that I have addressed all your issues.  Can you
> >> please check the latest rev?  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 particular, Section 5.2, step 1, seems to assume that it always
> > gets a tmStateReference. But when the Dispatcher on e.g. command
> > generator (acting as SSH client) calls sendMessage for the first
> > time, it doesn't have a tmStateReference yet? (Or if it does have
> > a tmStateReference, where did it come from?)
> 
> 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.
> 
> > 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).
> 
> We don't need a tmStateReference cache entry to call openSession.  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.
> 
> -- Jeff
>