Re: [Isms] pre11 comments
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] pre11 comments
Hi,
The whole reason SNMPv3 is modular is that "you can please some of the
people all of the time, and all of the people some of the time, but
you can never please all of the people all of the time." Let's not try
to make SSHTM and SSHSM perfect for every environment. Let's make it
good enough to work for most of the people all of the time, i.e., for
most environments it is secure enough, and keep things modular so the
unpleased people can write their own alternative models to suit their
specific environments.
I will observe that the SNMPv2 and SNMPv3 WGs had all sorts of
requirements that demanded support for particular use cases. In
reality, all the people who raised these additional requirements never
bothered writing alternative models to support their use cases (to my
knowledge). And many of the options we included in the 80% solution
seem to be go unused.
I think the case Wes is concerned with happens 1% of the time, and
with thoughtful configuration can be reduced to 0.00763% of the time
(OK, I'll settle for 80/20). IFrom isms-bounces at ietf.org Thu Jul 3 19:58:55 2008
Return-Path: <isms-bounces at ietf.org>
X-Original-To: isms-web-archive at megatron.ietf.org
Delivered-To: ietfarch-isms-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CE6B63A6920;
Thu, 3 Jul 2008 19:58:55 -0700 (PDT)
X-Original-To: isms at core3.amsl.com
Delivered-To: isms at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 8CB2A3A6931
for <isms at core3.amsl.com>; Thu, 3 Jul 2008 19:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.263
X-Spam-Level:
X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.336,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3AncJCQwdIaW for <isms at core3.amsl.com>;
Thu, 3 Jul 2008 19:58:53 -0700 (PDT)
Received: from QMTA03.emeryville.ca.mail.comcast.net
(qmta03.emeryville.ca.mail.comcast.net [76.96.30.32])
by core3.amsl.com (Postfix) with ESMTP id 9DAAD3A6920
for <isms at ietf.org>; Thu, 3 Jul 2008 19:58:53 -0700 (PDT)
Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12])
by QMTA03.emeryville.ca.mail.comcast.net with comcast
id la2t1Z00C0FhH24A30Kv00; Fri, 04 Jul 2008 02:59:01 +0000
Received: from Harrington73653 ([222.128.247.81])
by OMTA08.emeryville.ca.mail.comcast.net with comcast
id leyl1Z0061m6Z1J8UeyqmK; Fri, 04 Jul 2008 02:58:59 +0000
X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=c9ccGq2RsLKWdT_vHowA:9
a=PtCLS5_GNA9sb2lQPa4A:7 a=uJ5Em4sTwvBOGVeKaBsnwpt0q48A:4
a=lZB815dzVvQA:10 a=50e4U0PicR4A:10
From: "David Harrington" <ietfdbh at comcast.net>
To: "'David B. Nelson'" <d.b.nelson at comcast.net>,
<isms at ietf.org>
References: <006401c8dc30$bac0af30$51f780de at china.huawei.com><sd63rmy615.fsf at wes.hardakers.net><4F599A473EF04ECD99F4C358B291245E at xpsuperdvd2><sdskuqwoli.fsf at wes.hardakers.net>
<00f401c8dd70$e2a997a0$6401a8c0 at NEWTON603>
Date: Fri, 4 Jul 2008 10:58:45 +0800
Message-ID: <024601c8dd81$e7c02c70$51f780de at china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcjdYhKu4yqqF6deSFOHxzlMfkTQswADduywAAJnr5A=
In-Reply-To: <00f401c8dd70$e2a997a0$6401a8c0 at NEWTON603>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Subject: Re: [Isms] pre11 comments
X-BeenThere: isms at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isms>,
<mailto:isms-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/isms>
List-Post: <mailto:isms at ietf.org>
List-Help: <mailto:isms-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>,
<mailto:isms-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: isms-bounces at ietf.org
Errors-To: isms-bounces at ietf.org
Hi,
The whole reason SNMPv3 is modular is that "you can please some of the
people all of the time, and all of the people some of the time, but
you can never please all of the people all of the time." Let's not try
to make SSHTM and SSHSM perfect for every environment. Let's make it
good enough to work for most of the people all of the time, i.e., for
most environments it is secure enough, and keep things modular so the
unpleased people can write their own alternative models to suit their
specific environments.
I will observe that the SNMPv2 and SNMPv3 WGs had all sorts of
requirements that demanded support for particular use cases. In
reality, all the people who raised these additional requirements never
bothered writing alternative models to support their use cases (to my
knowledge). And many of the options we included in the 80% solution
seem to be go unused.
I think the case Wes is concerned with happens 1% of the time, and
with thoughtful configuration can be reduced to 0.00763% of the time
(OK, I'll settle for 8 recommend writing TSM to handle the
80%, relying solely on the identity function, so we can avoid adding
yet another configuration table to SNMP. If this use case really is
perceived by operators as being a problem, a new diffTSM could be
created to include a table for differentiating between lower layer
transport protocols. TSM is an optional security model; for those 20%
environments where the differentiatioon is important, create another
optional modular security model and let operators use whichever they
prefer.
Following the 80% rule, I also recommend making it even clearer that
there is one and only one SSH session per address/name tuple, and all
securityLevel requests are shoe-horned into the one authpriv SSH
session per address/name. This avoids adding yet another configuration
table to SNMP. If somebody really **needs** to have three different
authpriv sessions that are differentiated by overloading the purpose
of tmSecurityLevel and calling the three authpriv sessions
"noAuthNoPriv", "authNoPriv", and "authpriv", that can be done in a
different SSH transport model.
Following the 80% rule, I suggest that reuse of sessions initiated for
a different direction be disallowed. The initiator of a session MUST
act as a client, and authenticate as a client using the user_auth
protocol standard. If somebody finds this to be problematic, they can
write an alternative transport model to solve that problem.
Following the 80% rule, I would also recommend making the filling-in
of the SSH user_name field mandatory for use with SSHTM. SSH makes the
user_name field mandatory, but whether it is filled in is optional
with some authentication mechanisms. I suggest simplifying things by
requiring that, for use with SNMP, the user_auth protocol MUST be
used, and the user name field MUST be filled in with a value that
identifies the principal being authenticated. Then we can use the
identity mapping in SSHTM as well, eliminating yet another SNMP
configuration table. Toolkits that do not always fill in this field
for user_auth, or do bnot make this field available to calling
applications, will not be suitable for use with SSHTM. This makes no
changes to SSH; it only states implementation/deployment requirements
for compliance with SSHTM.
dbh
> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On
> Behalf Of David B. Nelson
> Sent: Friday, July 04, 2008 8:57 AM
> To: isms at ietf.org
> Subject: Re: [Isms] pre11 comments
>
> Wes Hardaker writes...
>
> > Right now the VACM and the security model can be used together to
> > grant or deny access based on a particular security model. With
> > a generic "any sub-transport will do" security model not being put
> > in place (TSM) then we loose that ability.
>
> Correct. Apparently the WG decided early on that, indeed,
> "any protected
> transport will do". I think what you're effectively
> suggesting is that we
> should *not* have a general TSM, but a series of xSMs, where "x" is
a
> specific secure transport protocol. KSM surely falls into
> that pattern.
>
> Personally, I think it's very late for that kind of revision.
> However, if
> it can be "hacked in" without much disruption, I see no fundamental
> objection to adding that feature.
>
>
> _______________________________________________
> 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
0/20). I recommend writing TSM to handle the
80%, relying solely on the identity function, so we can avoid adding
yet another configuration table to SNMP. If this use case really is
perceived by operators as being a problem, a new diffTSM could be
created to include a table for differentiating between lower layer
transport protocols. TSM is an optional security model; for those 20%
environments where the differentiatioon is important, create another
optional modular security model and let operators use whichever they
prefer.
Following the 80% rule, I also recommend making it even clearer that
there is one and only one SSH session per address/name tuple, and all
securityLevel requests are shoe-horned into the one authpriv SSH
session per address/name. This avoids adding yet another configuration
table to SNMP. If somebody really **needs** to have three different
authpriv sessions that are differentiated by overloading the purpose
of tmSecurityLevel and calling the three authpriv sessions
"noAuthNoPriv", "authNoPriv", and "authpriv", that can be done in a
different SSH transport model.
Following the 80% rule, I suggest that reuse of sessions initiated for
a different direction be disallowed. The initiator of a session MUST
act as a client, and authenticate as a client using the user_auth
protocol standard. If somebody finds this to be problematic, they can
write an alternative transport model to solve that problem.
Following the 80% rule, I would also recommend making the filling-in
of the SSH user_name field mandatory for use with SSHTM. SSH makes the
user_name field mandatory, but whether it is filled in is optional
with some authentication mechanisms. I suggest simplifying things by
requiring that, for use with SNMP, the user_auth protocol MUST be
used, and the user name field MUST be filled in with a value that
identifies the principal being authenticated. Then we can use the
identity mapping in SSHTM as well, eliminating yet another SNMP
configuration table. Toolkits that do not always fill in this field
for user_auth, or do bnot make this field available to calling
applications, will not be suitable for use with SSHTM. This makes no
changes to SSH; it only states implementation/deployment requirements
for compliance with SSHTM.
dbh
> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On
> Behalf Of David B. Nelson
> Sent: Friday, July 04, 2008 8:57 AM
> To: isms at ietf.org
> Subject: Re: [Isms] pre11 comments
>
> Wes Hardaker writes...
>
> > Right now the VACM and the security model can be used together to
> > grant or deny access based on a particular security model. With
> > a generic "any sub-transport will do" security model not being put
> > in place (TSM) then we loose that ability.
>
> Correct. Apparently the WG decided early on that, indeed,
> "any protected
> transport will do". I think what you're effectively
> suggesting is that we
> should *not* have a general TSM, but a series of xSMs, where "x" is
a
> specific secure transport protocol. KSM surely falls into
> that pattern.
>
> Personally, I think it's very late for that kind of revision.
> However, if
> it can be "hacked in" without much disruption, I see no fundamental
> objection to adding that feature.
>
>
> _______________________________________________
> 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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
