Subject: [Isms] Tmsm#4: persistent session info

From: "David Harrington" <[email-masked]>
Date: Fri, 16 Feb 2007 08:57:49 -0500

>From Wes (1/9/07):

> -----
>    						      and if state
>    information is available when a session is closed, the 
> session state
>    information should also be released.
> 
> Unless the management system indicates that the state should remain
> around for a longer period of time to allow for data collection
about
> the session to occur.  See David Perkins for details.

Dbh response:
I can understand the desire to have session info last longer than the
session, but the state info (in the LCD) is used to determine if a
session exists, so keeping it around in the LCD might be problematic,
unless it is somehow marked as expired. Since we are not writing a MIB
to represent this, I am not sure how we want to address the
implications of this issue here.

I have not heard from Dave Perkins on this issue at all.

The LCD is implementation-specific; as compared to the rfc341x docs,
we are not defining the LCD in MIB modules, but leaving it entirely up
to implementers to decide whether to use an LCD, the format of the
LCD, and so on. We have explicitly stated that release of
memory/resources for the cache and LCD are implementation-specific.
Therefore, I think we probably do not need to say anything about this
issue. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Feb 2007 10:52:56 +0100

> Therefore, I think we probably do not need to say anything about this

I have not seen any further comments on this. Hence, I assume that we
like to define that "session state is released if a session is
closed". If you believe this is wrong, please speak up now.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Feb 2007 11:07:06 -0500

Hi,

> closed". If you believe this is wrong, please speak up now.

I believe the complaint is that we specified the state was released
when the session is closed; this should be an implementation decision,
since all release handling is implementation-specific.

The important point is we should not rely on any specific
implementation choice, so checking to see if the session is still in
the LCD to determine that the session has not been closed is
inappropriate in our document.

I changed the documents to reflect this implementation-specific view.

If we want more control over this, we should probably standardize the
LCD as a MIB module, with a RowStatus object per session. But that
opens a whole new can of worms.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Tuesday, February 27, 2007 4:53 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] Tmsm#4: persistent session info
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Feb 2007 17:31:59 +0100

> I changed the documents to reflect this implementation-specific view.

Dave, can you please post the new wording so that we can check whether
we agree with it?

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Feb 2007 13:16:16 -0500

Hi,

The LCD an implementation-decision, including the contents, whether
there is one at all, and when it should be released if there is one:

>From tmsm-06:
5.2.  tmStateReference

   For each message or transport session, information about the
message
   security is stored in a cache, which may include model- and
   mechanism-specific parameters.  The tmStateReference is passed
   between subsystems to provide a handle for the cache.  A Transport
   Model may store transport-specific parameters in the cache for
   subsequent usage.  Since the contents of a cache are meaningful
only
   within an implementation, and not on-the-wire, the format of the
   cache is implementation-specific.

   The state referenced by tmStateReference might be saved in a Local
   Configuration Datastore (LCD) to make it available across multiple
   messages, as compared to securityStateReference which is designed
to
   be saved only for the life of a request-response pair of messages.
   It is expected that an LCD will allow lookup based on the
combination
   of transportDomain, transportAddress, securityName, securityModel,
   and securityLevel, and that the cache contain these values to
   reference entries in the LCD.

>From TSM-03:
3.2.2.  tmStateReference

   For each transport session, information about the message security
is
   stored in a cache to pass model- and mechanism-specific parameters.
   The state referenced by tmStateReference may be saved across
multiple
   messages, in a Local Configuration Datastore (LCD), as compared to
   securityStateReference which is usually only saved for the life of
a
   request-response pair of messages.

   The format of the cache and the LCD are implementation-specific.

5.2.  Elements of Procedure for Incoming Messages
   8) The information in the tmStateReference may be saved, in an
   implementation-dependent manner, in a Local Configuration Datastore
   (LCD) for subsequent usage.

[Note that the LCD is not mentioned for outgoing messages.]

--
The SSH Transport Model is not as up-to-date as the other documents.
As previously discussed, I have been waiting for the architectural
issues and the transport-model-independent security model to gel
before getting into the details of the SSH model.

Currently, the SSH transport model does use an LCD - one that is
SSHTM-specific, and documented as SSHTM-MIB. It is actually not viable
at this point; much of it is just cut-and-pasted from USM with a
global replace operation to remove USM-specific details. It does not
and should not reflect SSH-specific information, such as the
encryption mechanism used by a session; that information should should
be made available through an SSH-MIB, designed by SSH experts to
document their protocol. Then the SSHTM-MIB can reference the SSH-MIB
as needed. 

I have to assume that the lack of an SSH-MIB is an IESG-approved
decision for the SecSH WG for security reasons, and we should not
presume to overturn such a decision by exposing SSH-specific info in
the SSHTM-MIB.

If we allow for transport model specific LCDs (which makes sense
architecturally), then sechell-xx might continue to define such an
LCD, even if the Transport Subsystem and the Transport Security Model
have no access to the model-specific LCD.

dbh

> Sent: Tuesday, February 27, 2007 11:32 AM
> To: David Harrington
> Cc: [email-masked]
> > > I have not seen any further comments on this. Hence, I assume
that
> > we

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 Feb 2007 10:20:37 -0800

>>>>> "DH" == David Harrington <[email-masked]> writes:

DH> I believe the complaint is that we specified the state was released
DH> when the session is closed; this should be an implementation decision,
DH> since all release handling is implementation-specific.

I'd suggest you word in a way it such that the following happens:

1) some state MUST be zeroized and freed immediately for security
   reasons (keys).
2) other state MAY be kept around by the implementation or released immediately.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Feb 2007 13:36:56 -0500

Hi wes,

I understand your concerns, but please understand we are at an
abstract level in these documents, and to the degree that we can, we
are outsourcing ALL knowledge of the transport security.  

I can certainly word the tmsm document to say "some state MUST be
zeroized and freed immediately for security reasons (keys), but which
state that is is model- and implementation-specific." 

I don't think does what you want, does it?

We could state in the specific transport-models that certain known
details about that transport be cleared, but WG consensus seems to be
we don't HAVE that information in the transport model; that is kept in
the secure transport layer, and we trust the transport layer to tell
us whether it has applied/will apply auth and priv services for us. We
do not store the keys or the parameters or any other secure-transport
information except possibly in an implementation-specific cache.  

To the greatest degree possible, the transport models do not KNOW any
transport-layer sensitive information.

dbh

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Tuesday, February 27, 2007 1:21 PM
> To: David Harrington
> Cc: [email-masked]; [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Feb 2007 16:49:46 +0100

> transport-layer sensitive information.

Can we please try to avoid over specifying every little detail? In our
prototype implementation, we simply tell the ssh library or the tls
library to close the session by calling the appropriate API function
and we trust that the libraries do a reasonable job.

Also note that TLS, for example, allows session resumption and if an
implementation chooses to take advantage of this, you only clear some
of the state associated with a session. The architectural documents
should allow for such things to happen in a given transport model and
not mandate that I can't support such nice features and that I have to
zero out something for which I have a valid reason to not zero it out.

We posted a -00 draft for a TLS transport and it describes how we
support TLS session resumption and IMHO the TLS transport model is the
right place to deal with this feature. But even then, we prefer to not
spell out what exactly needs to be zeroed since in implementation
terms, I trust openssl or gnutls to just do the right thing.

(I was speaking as a technical contributor - just in case. ;-)

/js