Subject: [Isms] ISMS #1: tmStateReference

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Jan 2008 21:46:07 +0100

ISMS #1: tmStateReference
Status: open

Section 4.1 of draft-ietf-isms-secshell-09.txt contains the following
text:

   The SSH Transport Model has the responsibility for explicitly
   releasing the complete tmStateReference and deleting the associated
   information when a session is closed.  [DISCUSS: does thi smean an
   admin cannot preconfigure informationi for connections?  How does
   this work with the TARGET-MIB?]

I do not understand the discuss, clearly not in the context of this
section.

Q1.1: What is the issue here? Or is this an editorial left over?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jan 2008 15:55:01 -0500

Hi,

tmStateReference contains information that may be
implementation-specific, and some of the information may need to be
static to allow preconfiguration of state in the target-mib and
associated tables.

The text says it is the responsibility of the transport model to
explicitly release the tmStateReference and associated information.
Should this be implementation-dependent, and if so, are there any
operational (e.g., notifications) or security issues with released or
non-released transport/security state?

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, January 23, 2008 3:46 PM
> To: [email-masked]
> Subject: [Isms] ISMS #1: tmStateReference
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 23 Jan 2008 16:35:09 -0500

> non-released transport/security state?

It sounds like "explicitly release" in this case means things like freeing 
the memory occupied by the tmStateReference or whatever it points to, or 
returning an object or identifier to a free pool.  Both the mechanism and 
timing of this, as well as who is responsible for doing it, seem highly 
implementation-dependent.  I don't think this is a detail we need to 
specify.

-- Jeff

---

From: "tom.petch" <[email-masked]>
Date: Fri, 25 Jan 2008 14:48:04 +0100

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "David Harrington" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 23, 2008 10:35 PM
Subject: RE: [Isms] ISMS #1: tmStateReference

> implementation-dependent.  I don't think this is a detail we need to

I think that that creates a security exposure.

There is no pointer on an outgoing message for which session to use.  The
(rather loose) binding is based on a match in the cache for
transportDomain/Address +  securityName/Level/Model so if a session with
instances of these objects is taken down and replaced by another with the same
instances, and the cache is not cleared when the session is taken down, then the
outgoing message could go over an inappropriate session.  So I think yes,
session failure MUST clear cache.

Tom Petch

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 25 Jan 2008 15:38:45 -0500 (EST)

On Fri, 25 Jan 2008, tom.petch wrote:

> transportDomain/Address +  securityName/Level/Model

You've said this before, but I can find no text which supports that
assumption.  As far as I know, we require that responses go out over the
same session as the incoming message, but leave the exact details of how
to handle that up to the implementation.  Naturally, any implementation
would have to take care to get the right session, regardless of what
approach is used.

That said, I can appreciate your point about not wanting to reuse a
session that is no longer active.