Subject: Re: [Isms] ISMS #1: tmStateReference

From: "David Harrington" <[email-masked]>
Date: Mon, 25 Feb 2008 12:55:25 -0500

Hi,

The text now says:

        The SSH Transport Model has the responsibility for explicitly
        releasing the complete tmStateReference and associated
        information when a session is closed.

I believe this addresses this issue. 

dbh

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Friday, January 25, 2008 8:48 AM
> To: Jeffrey Hutzelman; David Harrington; [email-masked]
> Subject: Re: [Isms] ISMS #1: tmStateReference
> 
> ----- 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
> 
> 
> > --On Wednesday, January 23, 2008 03:55:01 PM -0500 David
Harrington
> > <[email-masked]> wrote:
> >
> > > 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?
> >
> > 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.
> >
> 
> 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
> 
> > -- Jeff
> >
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> 
> 

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