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

[Jeffrey Hutzelman <jhutz at cmu.edu>]

--On Wednesday, February 25, 2009 12:20:52 PM -0500 David Harrington 
<ietfdbh at comcast.net> wrote:

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

Yes, but the processing must be consistent with the defined semantics of 
the ASI.  As currently defined, the tmStateReference parameter is not 
required to be "present and valid"; it could be not present or invalid, and 
that would be a legitimate call to sendMessage.  Therefore, either 
sendMessage must behave reasonably without a tmStateReference, or it must 
be perfectly clear both that SSHTM's sendMessage requires the parameter be 
present and valid, and that the transport model architecture permits a 
transport model to impose such a requirement.


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

How could USM-over-SSHTM possibly be _less_ secure than USM-over-TCP?
More generally, why would it be insecure to use SSHTM with a security model 
that does not provide a tmStateReference?

I agree that it would be insecure to use SSHTM with TSM if the TSM didn't 
pass a tmStateReference when needed (particularly, when tmSameSecurity 
needs to be true).  However, that would be due to a bug in the TSM 
implementation, not because using SSHTM without a tmStateReference is 
insecure.

I would also agree that a TSM which fails to pass a tmStateReference when 
tmSameSecurity is _not_ true is buggy, because the TSM spec requires it to 
always do so.  However, in the case of SSHTM, omitting tmStateReference is 
not even insecure; it just (probably) won't work, because the ssh 
connection won't get opened with the correct username and so the security 
names won't match on the other end.


In short, a TSM which doesn't pass a tmStateReference is buggy, because TSM 
is required to pass one, and because doing so is required for the security 
of TSM in some cases.  However, a security model which doesn't pass a 
tmStateReference to SSHTM is not automatically insecure; USM could care 
less what SSH username is used.


> > We don't need a tmStateReference cache entry to call openSession.
>
> The way it is currently defined you do

And I described a way in which it could be redefined such that knowledge of 
tmStateReference and of the cache entries is contained only within 
sendMessage and is not needed in openSession, by passing down the SSH 
username to use instead of the tmStateReference.

Note that I did _not_ suggest attempting to derive the ssh username from 
the securityName passed in the ASI's.  I suggested that it be left 
unspecified, leaving the SSH layer free to figure it out on its own.  The 
reasoning is that if you're not using a security model which depends on the 
transport model using a particular tmSecurityName (and thus on SSH using a 
particular username), then the SSH layer's guess is likely to be at least 
as good as SNMP's, and possibly quite a lot better.


For example, suppose I use some management app on my desktop computer to 
send commands to SNMP agents on a variety of remote systems.  For some 
reason, I decide I want to use USM over SSHTM to talk to some of those 
systems.  In that case, the app is probably using an SNMP library whose 
SSHTM implementation works by calling out to whatever SSH implementation is 
already on the machine.  After all, that's one of the reasons for reusing 
SSH.  Now, that SSH implementation, if not given a username, is likely to 
do something like assume that it should use my local username, and my 
existing ssh keys (or whatever other credentials).  Chances are, every 
device I want to talk to falls into one of two categories.  Either the SSH 
default behavior works, or _nothing_ will work.



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

SSHTM doesn't generate outgoing messages.  It transports messages provided 
by someone else.  Again, why is it bad or insecure for SSHTM to transport 
messages without a valid tmStateReference?


I think perhaps you're conflating two things here.

It's insecure to use TSM without a transport that _uses_ tmStateReference.
It's not insecure to use SSHTM without an SM that _provides_ it.

==========

All of that said, I think I'd be OK with simply imposing the requirement 
that SSHTM must only be used with TSM or another transport-aware security 
model which passes tmStateReference, and then requiring that 
tmStateReference always be present and valid.

However, if we want to do that, then SSHTM needs to _say_ that 
tmStateReference must always be present and valid.

Also, the transport model document (where did "TMSM" come from, anyway?) 
needs to make it clear that a transport model MAY impose this requirement. 
Conceptually, such a requirement must be visible across the abstraction 
(you have to _know_ that this SM meets the requirements of that TM), and 
TMSM defines that abstraction.


==========



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

Not quite; I think maybe there is a step needed in between....

- Step 3 quoted above is good as far as it goes.

- If tmSameSecurity is true and there _was_ an existing session found,
 then the tmTransportAddress and tmSecurityName must _also_ match,
 or processing stops in the same way described in step 3.

- If tmSameSecurity was _not_ true, then we still need to look for an
 existing session matching tmTransportAddress and tmSecurityName prior
 to step 4.  Except I'm not sure if that's right....

 If tmSameSecurity is not true, do we want to reuse an existing session
 ever, or always create a new one?  We may have already discussed this,
 but I don't recall the answer.