Re: [Isms] Multiple user namespaces (was RE: pre11 comments)

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Mon, Jul 28, 2008 at 11:30:57AM -0400, David B. Nelson wrote:

> > Playing devil's advocate: Why do we need have to standardize
> > this?
> 
> I suppose if the use of the "tag" is entirely within the scope of an
> implementation, e.g. it does not appear in any MIB objects, we need not
> standardize it.  It's only when the choices made by disparate
> implementations are exposed to organization-wide management tools that we
> require consistency.  It's not [yet] clear to me that the "tags" are
> "private data" of the implementation, and not exposed to other systems.  The
> discussion of mapping tables leaves open the possibility that the "tags" are
> "public data".
> 
> > As far as I can tell, the mapped name only has to be consistent
> > with the local ACM policy.
> 
> Well, doesn't that expose the "tags" to other systems?  In a mulFrom isms-bounces at ietf.org  Mon Jul 28 09:04:08 2008
Return-Path: <isms-bounces at ietf.org>
X-Original-To: isms-archive at megatron.ietf.org
Delivered-To: ietfarch-isms-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2D9D328C1F3;
	Mon, 28 Jul 2008 09:04:08 -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 B7BEA28C1AE
	for <isms at core3.amsl.com>; Mon, 28 Jul 2008 09:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.04
X-Spam-Level: 
X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.209, 
	BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 c8LKTOZAhnnV for <isms at core3.amsl.com>;
	Mon, 28 Jul 2008 09:04:01 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de
	[212.201.44.23])
	by core3.amsl.com (Postfix) with ESMTP id 0896528C1F4
	for <isms at ietf.org>; Mon, 28 Jul 2008 09:04:01 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49])
	by hermes.jacobs-university.de (Postfix) with ESMTP id 58D15C0041;
	Mon, 28 Jul 2008 18:04:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23])
	by localhost (demetrius4.jacobs-university.de [212.201.44.32])
	(amavisd-new, port 10024)
	with ESMTP id plrk39NATnLs; Mon, 28 Jul 2008 18:03:57 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133])
	by hermes.jacobs-university.de (Postfix) with ESMTP id E9B88C000A;
	Mon, 28 Jul 2008 18:03:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501)
	id BD91B678E28; Mon, 28 Jul 2008 18:03:56 +0200 (CEST)
Date: Mon, 28 Jul 2008 18:03:56 +0200
From: Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>
To: "David B. Nelson" <dnelson at elbrysnetworks.com>
Message-ID: <20080728160356.GA8708 at elstar.local>
Mail-Followup-To: "David B. Nelson" <dnelson at elbrysnetworks.com>, isms at ietf.org
References: <20080728144229.GA8421 at elstar.local>
	<01F0572D5B3C4A3F96F9B3FBA9DFF78E at xpsuperdvd2>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <01F0572D5B3C4A3F96F9B3FBA9DFF78E at xpsuperdvd2>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: isms at ietf.org
Subject: Re: [Isms] Multiple user namespaces (was RE:  pre11 comments)
X-BeenThere: isms at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: j.schoenwaelder at jacobs-university.de
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

On Mon, Jul 28, 2008 at 11:30:57AM -0400, David B. Nelson wrote:

> > Playing devil's advocate: Why do we need have to standardize
> > this?
> 
> I suppose if the use of the "tag" is entirely within the scope of an
> implementation, e.g. it does not appear in any MIB objects, we need not
> standardize it.  It's only when the choices made by disparate
> implementations are exposed to organization-wide management tools that we
> require consistency.  It's not [yet] clear to me that the "tags" are
> "private data" of the implementation, and not exposed to other systems.  The
> discussion of mapping tables leaves open the possibility that the "tags" are
> "public data".
> 
> > As far as I can tell, the mapped name only has to be consistent
> > with the local ACM policy.
> 
> Well, doesn't that expose the "tags" to other systems?  In a multi-vendor
> environment, wouldn't that mean that the configuration of ACM policy across
> the organization would need to be customized on a per-vendor basis?  I see
> that as a negative.
> 
> > Is this not good enough?
> 
> Maybe it's "too" good, i.e. it offers sufficient flexibility to inhibit
> multi-vendor interoperability (if not used carefully).

With USM and CSM, we have a mapping mechanism in place that allows
operators to _configure_ mappings as they see fit. With TSM, can we
not provide a similar mechanism allowing operators to _configure_
mappings when needed? The mappings then become part of the SNMP
configuration and I do not see a multi-vendor interoperability issue
(at least nothing worse than what we are used to ;-).

We need to figure out how we can keep simple installations simple and
put the costs on more complex installations. This might require to
think about a wildcarding mechanisms that allows me to specify a
policy such as "all SSH user names not listed in the table are passed
unaltered as securityNames" or "all TLS/DTLS names not found in the
table are mapped to a specific securityName (so VACM can deny access
for example)".

/js (still speaking as technical contributor)

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms


ti-vendor
> environment, wouldn't that mean that the configuration of ACM policy across
> the organization would need to be customized on a per-vendor basis?  I see
> that as a negative.
> 
> > Is this not good enough?
> 
> Maybe it's "too" good, i.e. it offers sufficient flexibility to inhibit
> multi-vendor interoperability (if not used carefully).

With USM and CSM, we have a mapping mechanism in place that allows
operators to _configure_ mappings as they see fit. With TSM, can we
not provide a similar mechanism allowing operators to _configure_
mappings when needed? The mappings then become part of the SNMP
configuration and I do not see a multi-vendor interoperability issue
(at least nothing worse than what we are used to ;-).

We need to figure out how we can keep simple installations simple and
put the costs on more complex installations. This might require to
think about a wildcarding mechanisms that allows me to specify a
policy such as "all SSH user names not listed in the table are passed
unaltered as securityNames" or "all TLS/DTLS names not found in the
table are mapped to a specific securityName (so VACM can deny access
for example)".

/js (still speaking as technical contributor)

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms