Re: [Isms] securityName

["Tom Petch" <nwnetworks at dial.pipex.com>]

----- Original Message -----
From: "Fleischman, Eric" <eric.fleischman at boeing.com>
To: "Tom Petch" <nwnetworks at dial.pipex.com>
Cc: <isms at ietf.org>
Sent: Tuesday, August 02, 2005 6:07 PM
Subject: RE: [Isms] securityName

Tom,

I am in harmony with using SSH, TLS+/-SASL, or DTLS. I very much
appreciate the authentication system flexibility avaialable from these
approaches. (Yes, PKI == Certificates.)

However, I am not clear how we are planning on adding additional privacy
and authentication mechanisms and still leave SNMPv3 USM and VACM
untouched. Where are the interfaces between the two systems (the old and
new) being drawn?

--Eric

Eric

The intent of the architecture is that the message processing subsystem decodes
the ASN.1, finds a securityModel value and calls one of many coexisting xSM, of
which USM is currently the only one; so no problem in principle in adding anoSM
(or anoACM) with a different value.  Every xSM should be passed the same
parameters and return the same values, as per the ASI in the SNMPv3
Architecture.  Trouble is, when security is
done at transport level (SSH, TLS), the security is best done before ever the
PDU gets to the message processing subsystem so its calls, eg to get the PDU
decrypted, are somewhat meaningless.  So for me, the architecture does not allow
for transport level security and so needs flexing or changing; I don't see this
as a problem, others do.  Likewise, the transport level knows what
authentication has taken place, who the 'principal' is; no way to pass this on -
the security model is expected to produce it out of a hat from the
msgSecurityParameters for the message processing subsystem whereas, with
transport level security, the security parameters are no longer in the SNMP PDU
but part of the SSH/TLS header.

The architecture is fine when every thing is done in a self-contained manner
within the engine as with USM and VACM.  For me, it starts to fail whenever
anything is done elsewhere, when some other system is the primary source of
information (authentication, user to Group mapping etc) and SNMP is the slave or
cache of it.  This is not clear cut, I think we have wiggle room, but I see this
as one significant unresolved issue.  The TMSM I-D does cover much of this.

How to move forward?  Get a charter that clearly allows us limited change in the
Architecture that allows security and authorization to be performed outside the
engine seems best to me (I have now ducked behind a multi-layered,
over-engineered firewall but will reemerge to make the same point in due
course.:-)

Randy's reply takes a different perspective.

Tom Petch


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