Re: [Isms] pre11 comments

["David Harrington" <ietfdbh at comcast.net>]

Hi, 

> -----Original Message-----
> From: tom.petch [mailto:cfinss at dial.pipex.com] 
> Sent: Thursday, July 03, 2008 2:54 PM
> To: David Harrington; isms at ietf.org
> Subject: Re: [Isms] pre11 comments
> 
> ----- 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.

No. Leaving the final decision, not to the security subsystem, but to
the security model.
How the security **model** does it is up to the security model.
So the TSM can make the decision to use an identity mapping rather
than 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).

The transport model has the responibility for transforming the
transport-specific parameters into the tmStateReference format that
can be passed "up the stack".

Since the SSH transport model supports SSH, which allows various types
of identities, it may need to have a mapping table (or multiple
automatic algorithmic transforms).

> 
> I think too that there will still be an issue with 
> securityLevel, in that the
> MPM determines that, 

I'll look closer at this, but I think that might be an overstatement.
For outgoing, the application determines the requested securityLevel.
For an outgoing SNMPv3 message, the v3MPM determines how to pass this
requested level in the v3 message format.
For an outgoing SNMPv1/v2c the MPM does not pass this requested value.

For incoming messages, the MPM determines what was requested by the
sending entity, either by convention (snmpov1/v2c=noAuthNoPriv), or by
getting the requested level from the v3 message. But that is only the
requested level.

The securityModel has the responsibility for ensuring that the
securityLevel request is met. RFC3414 checks that appropriate security
properties are supported, and if not, it generates an
unsupportedSecurityLevel error. So it is the security model that
determines the actual security level used (USM checks that appropriate
entry in the usmUserTable has an auth protocol specified, if the
requested security includes auth, and checks that the user has a priv
protocol if priv is part of the request.

TSM does the same thing. It compares the requested security level
provided by the MPM and the actual security level asserted by the
transport model, and verifies that the incoming message has met the
requirement. For outgoing, the TMS specifies the requested security
level to the TM, and the tM verifies that the actual properties (as
far as we can determine) meets the requested level. 



> 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 ... )

There can be only one session for each transportdomia/address
securityname/level.
But with SSH, we ignore the requested level because SSH is always
authpriv.

I believe we state that very clearly:
"   Outgoing messages requested by SNMP applications and specified
with a
   lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by the
SSH
   Transport Model as authPriv securityLevel."

So the SSHTM will never call openSession() and get an SSH session that
is not authpriv.
It will open one session for the domain/address/name and that will be
authpriv. If a user asks that a message be sent over SSH with
noAuthNoPriv, it will be sent over the one authpriv session associated
with the domain/address/name. If a user asks that a message be sent
over SSH with authNoPriv, it will be sent over the one authpriv
session. If a user asks that a message be sent over SSH with authpriv,
it will be sent over the one authpriv session.

There will never be multiple sessions to differentiate between on the
basis of securityLevel.

> 
> 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