Re: [Isms] pre11 comments

["tom.petch" <cfinss at dial.pipex.com>]

----- Original Message -----
From: "David Harrington" <ietfdbh at comcast.net>
To: <isms at ietf.org>
Sent: Wednesday, July 02, 2008 12:45 PM
Subject: [Isms] pre11 comments


> Hi,
>
> I think the TSM should do a 1:1 translation from tmSecurityName to
> securityName, and vice-versa.
> I am not sure we need a securityName mapping table for TSM.
>

David

I am reading 1:1 as being the identity mapping from the context.

The history as I see it is that it is the Security Subsystem that comes up with
the model independent securityName identifying the principal, and how it does it
is up to it.  Hence leaving the final decision to it and hence a mapping table.
Pragmatically, I have no problem with making the Transport Model do all the work
but that might go against architectural considerations that have been voiced
here in the past (although not by me).

I think too that there will still be an issue with securityLevel, in that the
MPM determines that, and there is currently no mechanism for the MPM to pass
that back to the TM when an inbound message is received over a session that the
TM received (as opposed to instigated).  Inbound message, TM creates a table
with SSH and transport details, message arrives, TM adds securityName tothe
table.  But when an outbound message is later passed from dispatcher to TM, the
TM cannot index to a session because it was never told what the application
level securityLevel is that is associated with that session (yup, same problem
as I been raising since ... )

Tom Petch

> The mapping happens at the transport model from the transport-specific
> principal to the tmSecurityName. That mapping is obviously necessary.
>
> I see us adding options and complexity that I don't see operators
> asking for, such as administratively definable transform selection. I
> hope these really are needed.
>
> I agree that operators might want to disable SNMP use of a transport
> that is allowed on the device for other purposes. For that, a TSM
> domain table with an enable/disable object might be appropriate.
> However, since we specifically use an "snmp" subsystem, isn't it
> likely that an SSH config can control whether the user can use the
> snmp subsystem, much like they can decide to disable X11 forwarding?
> and even if they do get in, then VACM can prevent them from being able
> to do anything snmp-related. So do we actually need to provide this
> control?
>
> David Harrington
> dbharrington at comcast.net
> ietfdbh at comcast.net
> dharrington at huawei.com
>
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms

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