Re: [Isms] ISMS/SSH and notifications

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

Hi,

I think this discussion has gotten off-track because there are some
invalid assumptions floating around, due to using the terms loosely
and not keeping the interfaces in mind.

I will correct a couple here. I will correct others in other emails.

> > 3. VACM Authorization
> > 
> > Here's where the important note discussed above comes into play:
the
> > VACM doesn't care how the securityName passed to it was derived
and
> > authenticated.  It's not the job of the VACM to do that.  It
trusts
> > the CR and NG engines to have done the right thing security wise.

Actually, that is not quite true. It is true that VACM does not care
which algorithm within a security model was used to perform
authentication, but it does care which securitymodel was invoked to do
the job. 

There is a big difference between the community security model, the
USM security model, and the TSM security model, so there may be a big
difference between community/dbh, USM/dbh, and TSM/sbh.

The IsAccessAllowed() ASI passes certain values, and it is expected
that those values will somehow be used to index the access control
tables. As with almost everything in SNMPv3, it is expected that
securityModel, securityName, and securitylevel are likely to be used
as indices to security information, and contexts and OIDs will be used
to reference data subsets.  

   statusInformation =              -- success or errorIndication
     isAccessAllowed(
     IN   securityModel             -- Security Model in use
     IN   securityName              -- principal who wants to access
     IN   securityLevel             -- Level of Security
     IN   viewType                  -- read, write, or notify view
     IN   contextName               -- context containing variableName
     IN   variableName              -- OID for the managed object
          )


--

I have concerns that Wes's email was misleading about how the target
table and parameters table are used. Please look at Appendix A in the
TSM document to see how the values from these tables are used by TSM.
Wes's email does not follow the Appendix, and fills in some fields
incorrectly, like roughly specifying a transport model (SNMP/SSH)
where an explicit securityModel enumeration is definitely called for. 

To repeat myself: as with almost everything in SNMPv3, it is expected
that securityModel, securityName, and securitylevel are likely to be
used as indices to security information. The securityModel/Name/Level
tuple will be needed to index into other tables as the processs goes
through the elements of procedure.

--

I think we will get into trouble if we keep talking about the NG and
NR doing security and transport things. The NG (actually it should be
NO) and the NR are applications. Transport model processing should not
be aware of what the operation is, because it only gets the wholeMsg
already formed, and possibly with the PDU encrypted by the security
model; the modularity of SNMPv3 means the transport model does know
what operation the message contains, and it should never look into the
PDU. 

It is an RFC3411-architectural-layer violation to have the transport
model know the operation type.

I know Wes's implementation may not follow the architectural layering
of the standard, but RFC3411 is the standard, and should abide by it
in our designs, or explicitly (not by sloppiness) re-architect SNMP.

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