Re: [Isms] pre11 comments

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> On Fri, 4 Jul 2008 11:58:54 +0800, "David Harrington" <ietfdbh at comcast.net> said:

DH> I don't think VACM is designed to operate differently based on the
DH> security protocol.

But it is; that's my point...  And we're loosing that.  The security to
group table is indexed by the model and the name that the model provides:

  +--vacmSecurityToGroupTable(2)
     |
     +--vacmSecurityToGroupEntry(1)
        |  Index: vacmSecurityModel, vacmSecurityName
        |
        +-- ---- INTEGER   vacmSecurityModel(1)
        +-- ---- String    vacmSecurityName(2)
        +-- CR-- String    vacmGroupName(3)
        +-- CR-- EnumVal   vacmSecurityToGroupStorageType(4)
        +-- CR-- EnumVal   vacmSecurityToGroupStatus(5)

It provided the ability for "wes" in USM land to be different than "wes"
in KSM land.  Or the same; it was an operator decision.

Now with the ISMS based solution then all future transport protocols
operating as a TM underneath TSM will always have identical
securityNames mapped to the same group and there is no way to change
that.  "wes" in SSH will have to be equivalent to "wes" in TLS because
the model number will be constant for both (which will be the enum value
for TSM).

The WG needs to make a decision whether we care about this or not.  It
will mean that "wes" will be locked into the same group regardless of
whether the transport is SSH or any other future transport from now on
that is TM/TSM based, be it TLS, DTLS, or TELNET (yeah, I know...).
The point, though, is that there will be no separation from an access
right like we already have today with a different security model number
per security feature set.  Maybe we're willing to live with that; but I
personally think it's short sighted.

DH> In USM and SNMPv1 and SNMPv2c community-based security models, whether
DH> auth and priv are asserted is based on a binary decision

It has nothing to do with auth/priv decisions (well; it's related but it
wasn't part of the point I was trying to make).

DH> If an operator does not feel the underlying protocol really provides
DH> adequate authpriv support, then they should configure it to not be
DH> used with SNMP. I do not support TSM having a table to decide whether
DH> "auth" is "auth enough" or "priv" is "priv enough".

I think you're missing my point.  Again, I'm not at all making
suggestions that we map specific auth/priv algorithms into VACM
decisions.  We don't do that with the USM now and I'm not proposing we
add such a new feature.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms