Re: [Isms] pre11 comments

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

Hi,

I think I do see the point.
The TSM model makes one assertion about whether authpriv is provided.
We need to decide whether a single assertion from the security model
is adequate, if the security model can "outsource" to different
lower-layer transports.

Do we need to make it possible for the administrator to provide a
mapping to different securityNames or different asserted
securityLevels based on the administrator's assumption of the strength
of the underlying transport.

I believe the SNMPv3 WG made the conscious decision that trying to
assess the strength of an underlying security mechanism, whether it is
at the SSH vs TLS level, or the DES vs AES level, is so difficult to
get right, and depends so much on the environment to which it is being
applied, that it is not worth trying to do this **within** SNMP. An
admin can control this better by determining whether and how to deploy
the underlying security mechanism.

I believe we should work with the same assumption - that an admin can
control this better by deciding how to deploy the underlying security
mechanism, whether it is at the SSH vs TLS level or the DES vs AE。

If an admin does not think SSH is adequate for SNMP, then they should
not authorize the creation of an SNMP subsystem in their SSH config.
Problem solved. No MIB tables to configure.

dbh

> -----Original Message-----
> From: Wes Hardaker [mailto:wjhns1 at hardakers.net]
> Sent: Friday, July 04, 2008 12:41 PM
> To: David Harrington
> Cc: 'Wes Hardaker'; 'David B. Nelson'; isms at ietf.org
> Subject: Re: [Isms] pre11 comments
>
> >>>>> 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