Re: [Isms] tm table was Re: pre-08 for TSM document
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isms] tm table was Re: pre-08 for TSM document



On Fri, Jun 27, 2008 at 12:49:25PM +0200, tom.petch wrote:
 
> On an incoming call, the SSHTM will know transport addresses, ports
> and type, SSH user name, SSH host name and will have an SSH session
> identifier; I assume that this will be stored in an internal SSHTM
> table(or cache).  When a message subsequently arrives over that
> session, SSHTM cannot know the securityLevel or securityName (as
> generated by the message originator), the former is buried in the
> ASN.1, the latter is the province of the SM not the TM.

The TM caches the authenticated identity and passes this on via the
tmStateReference. The SM picks up the value, it knows which TM has
passed the tmStateReference, and it knows the actual security level
and can check them.
 
> So on an outgoing message at some later time, it cannot match the
> 4-tuple of transportDomain and transportAddress, securityName and
> securityLevel that is used elsewhere in the stack to identify the
> session to be used for a message.  I thought that snmpTsmLCDTable
> would provide an answer but I don't see it.

Why not? What do you think is missing?

> (The SSHTM I-D says
> "     1) Determine the target index by extracting the transportDomain,
>       transportAddress, securityName, and securityLevel from the
>       tmStateReference.
>       2) Lookup the session in the Local Configuration Datastore using
>       the target index " )

I do not yet see why it won't work. Please explain.

/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
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.