Re: [Isms] Comments on the BTSMS proposal (fwd)

[Juergen Schoenwaelder <j.schoenwaelder at iu-bremen.de>]

On Wed, Aug 03, 2005 at 03:53:50AM -0700, David T. Perkins wrote:

> On the question about what to put in the security param
> field (and security type) when using encapsulated security -
> I suggest either:
> 1) nothing - a zero length string (and the security model (SM)
>    session ID would be determined by the "SSH session"; or
> 2) a session ID pair - the security model (SM) processing code
>    would take the session ID pair and verify that the
>    "SSH session" matches.

In option 2) requires that the secure transport makes such session
identifiers available - not sure every potential secure transport
protocol will give you such identifiers. If you want to pass the
session identifier from the local session endpoint up to the security
model, then using a state reference seems to be much simpler.

> I assume that there is a "table" (conceptual) of SM sessions.
> Each entry is identified by a session ID pair. Other info
> in the entry would include:
>  1) "encapsulation transport" info (for example, the info
>     for the "SSH session")
>  2) the security level provided by the encapsulating transport
>     (the values would be authNoPriv and authPriv, but maybe
>      also noAuthNoPriv)
>  3) the SM identity and the security name of the session
>      initiator
>  4) possibly, the SM identity and security name of the
>      session listner
>  5) possibly, the VACM group name
>  6) possibly, other values for "overrides" and other session
>      related attributes.
> 
> When an "encapsulation transport" session is created, entries
> would be added to the table. And when a session is terminated,
> then entries are removed from the table.

This table would basically export the tmStateReference cache described
in <draft-schoenw-snmp-tlsm-02.txt> - which may be useful just for
debugging purposes alone. However, I am rather strictly against a
solution which requires to populate something in such a table to make
things work.

> I believe that the above approach works for and SSH "encapsulation
> transport" session, and will also work for other session
> based SMs. And I believe that it resolves the issue about
> how the values from SNMP messages for flags to security level
> is determined, and how to use the values in the security params
> field.

Yes. I also think that should figure out how sessions are initated,
identified and used in generic terms. RFC 3430 has some text on this
and I am not saying this approach is the right one or best one. But I
think it would be nice if session oriented protocols could share some
of this.

/js

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

_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms