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

From: "David Harrington" <[email-masked]>
Date: Mon, 9 Feb 2009 23:40:30 -0500

Hi Pasi,

Iam not certain that I have addressed all your issues. 
Can you please check the latest rev?
comments inline.

> Comments about draft-ietf-isms-secshell-13, Section 5:
> 
> Overall: I think we're *almost* done -- I think we need to fill in
> some minor details, but those shouldn't affect the overall
processing.
> 
> - The distinction between tmStateReference cache and LCD is a bit
> unclear -- do these actually mean the same thing? For example,
Section
> 5.3 talks about creating an LCD entry when the SSH client has
> established a connection (step 7), and Section 5.2 checks if the LCD
> entry exists (step 2).

I removed all references to an LCD.

> 
> But there's no text saying that the SSH server ever creates any LCD
> entries -- so step 2 of Section 5.2 would always fail when
> e.g. sending command responses. That's clearly not the intention.
> Section 5.1 does talk about creating a tmStateReference cache --
> perhaps it should talk about creating a LCD cache entry? Or perhaps
> Sections 5.2/5.3 should talk about tmStateReference cache? Or
perhaps 
> we need to describe opening a session also from SSH server's point 
> of view? (Section 5.3 talks only about what the SSH client does, and

> says basically nothing about what the server does.)

We now have no mechanism for storing any long-term information about a
connection from the server's point of view, or lomg-term information
about a connection from a ciient's point of view either.
All we have is the tmStateReference cache, and I don't know quite how
long that lives.

> 
> - Section 5.2 (step 2) says the LCD entry is indexed by
> (destTransportAddress,tmSecurityName) but 5.3 (step 7) says it's
> (destTransportAddress,tmStateReference). Probably the former is
> correct? (but in that case, there's no need to store tmSecurityName 
> in the entry itself, so step 7 of 5.3 may need some editing)
> 
> - Section 5.3, step 1: it would be *really* useful to add a note 
> that to authenticate the server, the client usually stores
> (destTransportAddress, server host public key) pairs in
> implementation-dependent manner.  (Otherwise, this text gets
difficult
> to understand.)

I rewrote this section to make it much cleaner. Hopefully, I got all
the steps right.

> 
> - Section 5.1: we shouldneed a better description of how 
> tmSecurityName
> works on the SSH client side; IMHO the current behavior isn't quite
> right: Suppose a command generator sends a command with
> tmSecurityName="alice" and
> destTransportAddress="[email-masked]:1234". An SSH
> connection is opened and so on. When the command response is
received,
> the current text in Section 5.1 would lead to having
> tmSecurityName="ahopkins" in the response -- a slightly unexpected
> response.  Would it be better to extract the tmSecurityName from the
> "LCD cache entry" (or whatever is the right term) that was created
> when the client first established the session?
> 
> - Section 5.1, on related note, on SSH client side, the
> tmTransportAddress in incoming messages should probably also be
> extracted from the "LCD cache entry", so that it's exactly the same
as
> was used for the outgoing message (that triggered creating the SSH
> connection).

It seems that needs to be done or the MPM will not match the response
to the outstanding request to determine to which application the PDU
must be delivered.

> 
> - Section 5.1, we should say what the tmTransportAddress for
incoming
> messages looks on the SSH server side: it's "address:port" form (not
> user@address:port).

under discussion.

> 
> - Typos:
> Section 5.3, "tmSecurtityName"
> Section 5.4, "sever"
> Several sections (including the MIB): 
> "sshtmSessionUnavaliableSubsystems"
> 
> Best regards,
> Pasi
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: <[email-masked]>
Date: Thu, 19 Feb 2009 09:03:58 +0100

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

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

Best regards,
Pasi

---

From: <[email-masked]>
Date: Thu, 19 Feb 2009 09:18:12 +0100

Oops -- please ignore this one; I just found where the
tmStateReference is created (transport-security-model,
Section 4.2).

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eronen Pasi (Nokia-NRC/Helsinki)
> Sent: 19 February, 2009 10:04
> To: [email-masked]; [email-masked]
> Subject: Re: [Isms] Comments about
> draft-ietf-isms-secshell-13, Section 5
>
> David Harrington wrote:
> >
> > Hi Pasi,
> >

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 19 Feb 2009 14:13:55 -0500

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

> 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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 19 Feb 2009 14:43:13 -0500

I'll look into this.

dbh 

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Thursday, February 19, 2009 2:14 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Wed, 25 Feb 2009 12:20:52 -0500

Hi,

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

comments inline. 

> > cache entry gets created on SSH client side (e.g. command 
[...]
> the sendMessage ASI needs to work even when tmStateReference 

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.

> > 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 
> and security ID? 
>  If so, and even if not, it seems that it may be 

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.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 25 Feb 2009 16:37:10 -0800

>>>>> On Wed, 25 Feb 2009 12:20:52 -0500, "David Harrington" <[email-masked]> said:

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

I agree with what you've said...  I think we can safely require that
if you wish to use the SSH transport we require a SM above that passes
down a tsmStateReference.  We could probably work around that, but I'm
not sure it's worth documenting for the standard.  It doesn't make it
"unmodular".  It doesn't even prevent an implementation from doing it,
because as we know implementations frequently don't exactly model the
"an" v3 architecture but are still protocol-on-the-wire conferment.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 Feb 2009 18:56:09 -0500

--On Wednesday, February 25, 2009 12:20:52 PM -0500 David Harrington 
<[email-masked]> wrote:

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

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

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

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

==========

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