From isms-bounces@ietf.org Wed Jul 2 03:45:24 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B67A3A6BCA; Wed, 2 Jul 2008 03:45:24 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1EB53A6976 for ; Wed, 2 Jul 2008 03:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 4Csf+wrn8K50 for ; Wed, 2 Jul 2008 03:45:17 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 901803A6BCA for ; Wed, 2 Jul 2008 03:45:15 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id kyVe1Z0040b6N64A201200; Wed, 02 Jul 2008 10:45:25 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id kylC1Z0011m6Z1J8PylHhg; Wed, 02 Jul 2008 10:45:23 +0000 X-Authority-Analysis: v=1.0 c=1 a=WTS_eNseHdxvJSEht50A:9 a=dV-7p5VIoNl0sr9SYDcA:7 a=lNqfOe22f2dhfN7kOjly_WTkiKUA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Wed, 2 Jul 2008 18:45:11 +0800 Message-ID: <006401c8dc30$bac0af30$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjcMLPhWZDatBQuS+WE0Fnxb9cAPg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I think the TSM should do a 1:1 translation from tmSecurityName to securityName, and vice-versa. I am not sure we need a securityName mapping table for TSM. The mapping happens at the transport model from the transport-specific principal to the tmSecurityName. That mapping is obviously necessary. I see us adding options and complexity that I don't see operators asking for, such as administratively definable transform selection. I hope these really are needed. I agree that operators might want to disable SNMP use of a transport that is allowed on the device for other purposes. For that, a TSM domain table with an enable/disable object might be appropriate. However, since we specifically use an "snmp" subsystem, isn't it likely that an SSH config can control whether the user can use the snmp subsystem, much like they can decide to disable X11 forwarding? and even if they do get in, then VACM can prevent them from being able to do anything snmp-related. So do we actually need to provide this control? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 2 06:53:42 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F8A3A6B96; Wed, 2 Jul 2008 06:53:42 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308E93A6AFD for ; Wed, 2 Jul 2008 06:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 4W1xxEG2dw6W for ; Wed, 2 Jul 2008 06:53:39 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id A63033A6B96 for ; Wed, 2 Jul 2008 06:53:39 -0700 (PDT) X-Trace: 105951067/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.113 X-SBRS: None X-RemoteIP: 213.116.52.113 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4EAPQka0jVdDRx/2dsb2JhbACDXjGHO6chAQI X-IronPort-AV: E=Sophos;i="4.27,737,1204502400"; d="scan'208";a="105951067" X-IP-Direction: IN Received: from 1cust113.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.113]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Jul 2008 14:52:31 +0100 Message-ID: <016e01c8dc41$bb497e80$0601a8c0@allison> From: "tom.petch" To: , "David Harrington" References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com><00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <20080627072519.GB2713@elstar.local> Date: Wed, 2 Jul 2008 10:48:59 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David Harrington" Cc: Sent: Friday, June 27, 2008 9:25 AM Subject: Re: [Isms] pre-08 for TSM document > On Thu, Jun 19, 2008 at 07:43:22PM +0800, David Harrington wrote: > > > I started calling this the snmpTsmUserTable, but that could be > > misleading, so I changed it the snmpTsmLCDTable. Let me know which > > you prefer, or if you have another name you prefer. > > I find snmpTsmLCDTable too broad; the snmpTsmLCDTransformTable is also > stored in the LCD. The table really is a snmpTsmSecurityNameMappingTable > or a snmpTsmTmMappingTable or a snmpTsmNameMappingTable. Or what about > snmpTsmTmNameTable? > I was going to suggest SessionTable since it is indexed by the 4-tuple that is used to determine which session is used, but then I recalled that s2.2 says that there are no sessions in TSM, rather the 4-tuple is used to associate state; so how about snmpTsmStateTable? Currently it is name only but it could acquire other columns, such as the tmSecurityLevel in use at the transport level or even parameters related to the underlying secure transport; I realise that this has been much discussed without consensus but I still would want something more neutral than NameTable to accommodate any gaps in our current understanding. TsmMapping would do, but not TsmNamemapping (too restrictive) Tom Petch > Nits: > > - s/2007/2008/ > > - The import of TEXTUAL-CONVENTION is not used. > > - Missing dot at the end of the first sentence in section 6.3.2. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 01:02:02 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C503A3A6A63; Thu, 3 Jul 2008 01:02:02 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE4C3A6A9B for ; Thu, 3 Jul 2008 01:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.860, 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 dcxmTgqzbPeK for ; Thu, 3 Jul 2008 01:02:00 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 950E33A68DB for ; Thu, 3 Jul 2008 01:01:59 -0700 (PDT) X-Trace: 140018130/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.122.229 X-SBRS: None X-RemoteIP: 62.188.122.229 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEAEBvV0g+vHrl/2dsb2JhbACLfaMHAw X-IronPort-AV: E=Sophos;i="4.27,742,1204502400"; d="scan'208";a="140018130" X-IP-Direction: IN Received: from 1cust229.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.229]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Jul 2008 09:02:05 +0100 Message-ID: <003e01c8dcd9$efd6b9e0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> Date: Thu, 3 Jul 2008 08:54:21 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "David Harrington" To: Sent: Wednesday, July 02, 2008 12:45 PM Subject: [Isms] pre11 comments > Hi, > > I think the TSM should do a 1:1 translation from tmSecurityName to > securityName, and vice-versa. > I am not sure we need a securityName mapping table for TSM. > David I am reading 1:1 as being the identity mapping from the context. The history as I see it is that it is the Security Subsystem that comes up with the model independent securityName identifying the principal, and how it does it is up to it. Hence leaving the final decision to it and hence a mapping table. Pragmatically, I have no problem with making the Transport Model do all the work but that might go against architectural considerations that have been voiced here in the past (although not by me). I think too that there will still be an issue with securityLevel, in that the MPM determines that, and there is currently no mechanism for the MPM to pass that back to the TM when an inbound message is received over a session that the TM received (as opposed to instigated). Inbound message, TM creates a table with SSH and transport details, message arrives, TM adds securityName tothe table. But when an outbound message is later passed from dispatcher to TM, the TM cannot index to a session because it was never told what the application level securityLevel is that is associated with that session (yup, same problem as I been raising since ... ) Tom Petch > The mapping happens at the transport model from the transport-specific > principal to the tmSecurityName. That mapping is obviously necessary. > > I see us adding options and complexity that I don't see operators > asking for, such as administratively definable transform selection. I > hope these really are needed. > > I agree that operators might want to disable SNMP use of a transport > that is allowed on the device for other purposes. For that, a TSM > domain table with an enable/disable object might be appropriate. > However, since we specifically use an "snmp" subsystem, isn't it > likely that an SSH config can control whether the user can use the > snmp subsystem, much like they can decide to disable X11 forwarding? > and even if they do get in, then VACM can prevent them from being able > to do anything snmp-related. So do we actually need to provide this > control? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 03:54:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29133A6AE4; Thu, 3 Jul 2008 03:54:03 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FECB3A6CE0 for ; Thu, 3 Jul 2008 03:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6] 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 y47NEX7sxK4f for ; Thu, 3 Jul 2008 03:54:01 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 3E3D83A6AE4 for ; Thu, 3 Jul 2008 03:54:01 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id lNZH1Z0020vp7WLA601f00; Thu, 03 Jul 2008 10:53:48 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id lNt01Z0011m6Z1J8RNtU8S; Thu, 03 Jul 2008 10:53:46 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=CJQObiVh1aiLPlfdyY4A:9 a=zVpKhu6WEdbP4nfxnvEA:7 a=3sjCtMAEaETIP6du7sJyNY6t7dgA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <003e01c8dcd9$efd6b9e0$0601a8c0@allison> Date: Thu, 3 Jul 2008 18:52:59 +0800 Message-ID: <015001c8dcfb$10e08230$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acjc40Vl+DXv4AqESt2KTpzLWCSHfwAEVzKQ In-Reply-To: <003e01c8dcd9$efd6b9e0$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Thursday, July 03, 2008 2:54 PM > To: David Harrington; isms@ietf.org > Subject: Re: [Isms] pre11 comments > > ----- Original Message ----- > From: "David Harrington" > To: > Sent: Wednesday, July 02, 2008 12:45 PM > Subject: [Isms] pre11 comments > > > > Hi, > > > > I think the TSM should do a 1:1 translation from tmSecurityName to > > securityName, and vice-versa. > > I am not sure we need a securityName mapping table for TSM. > > > > David > > I am reading 1:1 as being the identity mapping from the context. > > The history as I see it is that it is the Security Subsystem > that comes up with > the model independent securityName identifying the principal, > and how it does it > is up to it. Hence leaving the final decision to it and > hence a mapping table. No. Leaving the final decision, not to the security subsystem, but to the security model. How the security **model** does it is up to the security model. So the TSM can make the decision to use an identity mapping rather than a mapping table. > Pragmatically, I have no problem with making the Transport > Model do all the work > but that might go against architectural considerations that > have been voiced > here in the past (although not by me). The transport model has the responibility for transforming the transport-specific parameters into the tmStateReference format that can be passed "up the stack". Since the SSH transport model supports SSH, which allows various types of identities, it may need to have a mapping table (or multiple automatic algorithmic transforms). > > I think too that there will still be an issue with > securityLevel, in that the > MPM determines that, I'll look closer at this, but I think that might be an overstatement. For outgoing, the application determines the requested securityLevel. For an outgoing SNMPv3 message, the v3MPM determines how to pass this requested level in the v3 message format. For an outgoing SNMPv1/v2c the MPM does not pass this requested value. For incoming messages, the MPM determines what was requested by the sending entity, either by convention (snmpov1/v2c=noAuthNoPriv), or by getting the requested level from the v3 message. But that is only the requested level. The securityModel has the responsibility for ensuring that the securityLevel request is met. RFC3414 checks that appropriate security properties are supported, and if not, it generates an unsupportedSecurityLevel error. So it is the security model that determines the actual security level used (USM checks that appropriate entry in the usmUserTable has an auth protocol specified, if the requested security includes auth, and checks that the user has a priv protocol if priv is part of the request. TSM does the same thing. It compares the requested security level provided by the MPM and the actual security level asserted by the transport model, and verifies that the incoming message has met the requirement. For outgoing, the TMS specifies the requested security level to the TM, and the tM verifies that the actual properties (as far as we can determine) meets the requested level. > and there is currently no mechanism for > the MPM to pass > that back to the TM when an inbound message is received over > a session that the > TM received (as opposed to instigated). Inbound message, TM > creates a table > with SSH and transport details, message arrives, TM adds > securityName tothe > table. But when an outbound message is later passed from > dispatcher to TM, the > TM cannot index to a session because it was never told what > the application > level securityLevel is that is associated with that session > (yup, same problem > as I been raising since ... ) There can be only one session for each transportdomia/address securityname/level. But with SSH, we ignore the requested level because SSH is always authpriv. I believe we state that very clearly: " Outgoing messages requested by SNMP applications and specified with a lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by the SSH Transport Model as authPriv securityLevel." So the SSHTM will never call openSession() and get an SSH session that is not authpriv. It will open one session for the domain/address/name and that will be authpriv. If a user asks that a message be sent over SSH with noAuthNoPriv, it will be sent over the one authpriv session associated with the domain/address/name. If a user asks that a message be sent over SSH with authNoPriv, it will be sent over the one authpriv session. If a user asks that a message be sent over SSH with authpriv, it will be sent over the one authpriv session. There will never be multiple sessions to differentiate between on the basis of securityLevel. > > Tom Petch > > > The mapping happens at the transport model from the > transport-specific > > principal to the tmSecurityName. That mapping is obviously > necessary. > > > > I see us adding options and complexity that I don't see operators > > asking for, such as administratively definable transform > selection. I > > hope these really are needed. > > > > I agree that operators might want to disable SNMP use of a transport > > that is allowed on the device for other purposes. For that, a TSM > > domain table with an enable/disable object might be appropriate. > > However, since we specifically use an "snmp" subsystem, isn't it > > likely that an SSH config can control whether the user can use the > > snmp subsystem, much like they can decide to disable X11 forwarding? > > and even if they do get in, then VACM can prevent them from > being able > > to do anything snmp-related. So do we actually need to provide this > > control? > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 09:43:00 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6EA3A6A35; Thu, 3 Jul 2008 09:43:00 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039C73A67FA for ; Thu, 3 Jul 2008 09:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, WEIRD_PORT=0.001] 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 rCjf7LM+KFse for ; Thu, 3 Jul 2008 09:42:57 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 09C3A3A69B0 for ; Thu, 3 Jul 2008 09:42:56 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 8B8C42C339E for ; Thu, 3 Jul 2008 09:43:05 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:subject:organization:date:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=joUbwGNvcgZ1lB4nBVrnhJVgUOU=; b=Umwn3HJ0ml+asyCYnioW/bWfR8i5TmTZY33vcMJKGl22zvw20m2gMDUm49lCPzh07s/yGXXIPGaDvFemBYHWXgFP21LMtiKBm4tQGSyN4SIJIOHfWdl1qD1LYj0CLTSn72OB8kE1ysFUjqSPfH7KDGxe9KI/exFJ1Si+u1F9w7Y= Received: by wes.hardakers.net (Postfix, from userid 274) id 6A6AC2C339C; Thu, 3 Jul 2008 09:43:05 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 03 Jul 2008 09:43:05 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I promised David a while ago to write this thought up... I'm a bit late in getting it out the door though. Current the SnmpSSHAddress TC offers flexible support to accommodate a name, a v4 address and a v6 address (surrounded by brackets) and by a port number. Thus the following values are legal: 127.0.0.1:161 host.example.com:161 [::1]:161 (if I read everything correctly). First, a quick issue: (which will be new to you Dave since I noticed it after our discussion) is that the text about IPv6 says "surrounded by brackets" which is not deterministic since there are two types of brackets. I assume you mean square brackets, because that's common usage, but it should be spelled out (maybe using the ASCII character numbers 0x5B and 0x5D like you did for the colon). Second, SSH has a fairly common usage that allows one user on one host to connect as a different user on the remote host. Right now in the SSHSM solution it's not possible to use a different remote user than the one specified locally even though this is common usage within SSH users today. To fix this, I'd like to suggest another *optional* portion on the front of the string that allows specifying the SSH user name to be used. Specifically, the "@" sign (ASCII 0x40) in the address string would be a delimiter to indicate that the beginning portion is a user name. The @ symbol don't exist legally in the existing specification so it shouldn't conflict with the existing structure and is easy to quickly look for and parse out. (and it is already common usage within at least some SSH implementations). Thus a transport address might look like these (in addition to the above still being legal): wes@127.0.0.1:161 wes@host.example.com:161 wes@[::1]:161 What's the benefit? ---------------------------------------- A separation of the local securityName from the remote user used to authenticate to the remote connection. SSH users use this all the time because their local identity name is different than the remote (I'm "hardaker" on my local system, but "whardaker" on others). From an SNMP standpoint, I could use a single local username to do VACM and other local information checks ("hardaker") but ssh-login to the remote site using different names as needed and specified by the transport address. The only thing this affects is the SSH transport that uses the address string. And because some SSH stacks already support this, it's possible they can still just pass the string along as is. Operators already understand the usage (and may expect that it'd work). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 15:08:49 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333C63A694A; Thu, 3 Jul 2008 15:08:49 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB67A3A694A for ; Thu, 3 Jul 2008 15:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_53=0.6] 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 OFGN-9zRRX8a for ; Thu, 3 Jul 2008 15:08:46 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 74E493A683C for ; Thu, 3 Jul 2008 15:08:46 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 22665399A83; Thu, 3 Jul 2008 15:08:55 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=P5gYHIhJ4hbwrEcdTwK5vhQ0+44=; b=t+IyhWmUtFYXgCLgZvjQWmOUiz7LsH5fTvOnzNUNwdAebNL/sDT1ilb0kPCvq7ugogaxsSPAY9nkdXb4enRpNd3rMrpmYdjoFKId9PPup7aymRZgGjbydJB6YcriawjvFyNHNUtv4IBcbNMl4icxevDh9r5W0ifnr82yGDpSjRc= Received: by wes.hardakers.net (Postfix, from userid 274) id 914BE399A84; Thu, 3 Jul 2008 15:08:54 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> Date: Thu, 03 Jul 2008 15:08:54 -0700 In-Reply-To: <006401c8dc30$bac0af30$51f780de@china.huawei.com> (David Harrington's message of "Wed, 2 Jul 2008 18:45:11 +0800") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 2 Jul 2008 18:45:11 +0800, "David Harrington" said: DH> I think the TSM should do a 1:1 translation from tmSecurityName to DH> securityName, and vice-versa. I am not sure we need a securityName DH> mapping table for TSM. DH> The mapping happens at the transport model from the transport-specific DH> principal to the tmSecurityName. That mapping is obviously DH> necessary. The current state of affairs, with a unique SM based security name per security model lets the VACM carefully distinguish which securityName gets authorization based on which model it comes from. Thus: securityName:wes model:USM can be given greater or lower access than: securityName:wes model:KSM This may be necessary because local policy dictates that kerberos (KSM in the above example) is considered "more secure" than the USM model for some reason or another. The wes/USM may not be given access to some critical infrastructure that the wes/KSM model is given. Fast forward to the new TSM model. Now we have only a single model to distinguish ourselves with and regardless of whether SSH or TLS is used under the hood, we have no selection criteria to use within the VACM to grant preferred access to TLS users over SSH users. But we may trust one protocol over another for one reason or another (possibly because we suddenly found a bug in the implementation of one protocol that suddenly renders it less secure so we'd rather lower the allowed access level to read-only until the implementation is fixed but the other protocol is still just fine so it can stay at read-write). The VACM *only* has the securityModel and securityName at it's disposal to make the distinction between how to grant authorization to a given remote entity (ok, it also has context and level information, but that doesn't help). This all means that *if* we want to allow separate authorization levels for different secure transports (and I'll argue that we do want to) we either need to: - use different securityModel numbers per transport, which the WG has already decided not to do (although it could be revisited I suppose and could be done with a careful IANA controlled mapping of TM domain numbers to security models all which in the end "mean" TSM). - say it's up to the user to ensure duplication doesn't happen. But if we want to make use of existing infrastructure, you're now imposing something on the user base they may not have had to deal with because right now SSH and TLS may have colliding user names but it's not a problem because one is authorizing shell access and the other a web database and authorization rights are already different). - OR: (*) Provide a mapping system so that identical user names from different security protocols can be mapped to different internal securityNames for things like authorization checks. The questions so far: - Do we want to provide different authorization checks per security transport? I think most will agree this would be good. - Do we want to require identity mapping capability so that identity X on transport SSH can be different than identity X on TLS. I personally think this would be good to have. - Do we want to provide a standardized mapping for mapping X/TLS and X/SSH to (eg) securityName's X and Y... I'd argue yes, since without a standardized mapping system then there will be inconsistency. So, *if* we want to do a mapping where should it go? There are really 3 choices: - Put it in the TSM document. The TSM could map between incoming securityNames offered by the transport and use that combined with the transportDomain to map to a value the application should use. This makes the TSM a bit more aware of the transport protocol that is in use, but it already had access to the transportDomain in the tmStateReference anyway so it's really nothing new. - Put it in the TM document and have a common mapping table, indexed in a similar way. The TM would use pass this into the rest of the engine. This gives more consistency in the value passed around the engine, which is probably a plus. - Have each TM implementation to provide a mapping table. This would mean that if SSH wanted to play nice with the above discussed model, it would have to add a mapping table from a local SSH specific identity name to a SNMPv3 specific securityName. It would be up to the TM document to say whether each TM implementation MAY, SHOULD or MUST provide such a mapping. I don't like the idea of the third choice because it's too much duplication. The other two require a single table, indexed by transportDomain and tmSecurityName, and it works for all instantiations of a TM regardless of whether they're standardized or not. I do think such a mapping is needed because security needs to differ and the cost is not high. In the real world, security changes too and it's much cheaper to put in such a mapping now so that authorization can be changed in the field in an emergency situation without disabling the entire protocol when it may still be safe to do some level of "monitoring" even if config isn't safe (e.g.). Right now, with only a single transport in the works, this problem isn't as apparent and this is simply good future planning. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 15:40:18 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4073A68A1; Thu, 3 Jul 2008 15:40:18 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295163A68A1 for ; Thu, 3 Jul 2008 15:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.631, 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 VdCG4gX4H8qS for ; Thu, 3 Jul 2008 15:40:16 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 3777F3A6868 for ; Thu, 3 Jul 2008 15:40:15 -0700 (PDT) Received: (qmail 31547 invoked from network); 3 Jul 2008 18:40:19 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 3 Jul 2008 18:40:19 -0400 From: "David B. Nelson" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> Date: Thu, 3 Jul 2008 18:40:20 -0400 Organization: Elbrys Networks, Inc. Message-ID: <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjdWWSeabg6lHqfTPmXu4QOBKzHEgAA2V3A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker writes... > This all means that *if* we want to allow separate authorization > levels for different secure transports (and I'll argue that we > do want to)... Well, yeah, but where do we stop? Someone might argue that the transport protocol alone isn't enough. Maybe they want to add cipher-suite into the selection. Or maybe key length, or maybe the specifics of the certificate chain. I could go on and on, specifying all sorts of security properties of the transport that conceptually *could* make a significant difference in *some* scenario. I think that we should keep this very simple. For that reason, I'm not convinced that we need to sub-specify the TSM by its underlying protocol. If a particular protocol is "compromised" the operator always has the option to simply de-configure it. Let's solve the "80% problem" and declare victory. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 16:10:44 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D453A6A40; Thu, 3 Jul 2008 16:10:44 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1933A6AC3 for ; Thu, 3 Jul 2008 16:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 IteceuV0Bxw2 for ; Thu, 3 Jul 2008 16:10:41 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 28E583A6A40 for ; Thu, 3 Jul 2008 16:10:41 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 875AB399A83; Thu, 3 Jul 2008 16:10:49 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=pXBUfyk6BQNM2zj163Fe8LTggPk=; b=iJCKnM8SDU6UUE4gebWTFQtulpp0r5Vr7Ps2L3J/qDomgDdFQPjZ0cJtvDvJ/R354vRNiH8Wt0gmV1BrFIBH0625WpQypliq+fMVaA0WGn2Zm0Q7pSMNqLqZSWmIPfcG9dt3kr9l3+Gfmr64L56l8N9B6XffsdJ6+j0zVn/c57E= Received: by wes.hardakers.net (Postfix, from userid 274) id 56C24399A84; Thu, 3 Jul 2008 16:10:49 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> Date: Thu, 03 Jul 2008 16:10:49 -0700 In-Reply-To: <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> (David B. Nelson's message of "Thu, 3 Jul 2008 18:40:20 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Thu, 3 Jul 2008 18:40:20 -0400, "David B. Nelson" said: >> This all means that *if* we want to allow separate authorization >> levels for different secure transports (and I'll argue that we >> do want to)... DBN> Well, yeah, but where do we stop? 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. I'm not trying to gain ground by doing cipher-suite selection (that can still be left up to the individual transport model's configuration since it's very specific to it). What I do think we're loosing, though, is the ability to select an authorization set based on the protocol being used itself (like we used be able to select between USM and KSM). I don't think we should go further than that, because further than that wasn't ever in the original SNMPv3 architecture either. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 17:56:54 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20633A688B; Thu, 3 Jul 2008 17:56:54 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA44F3A688B for ; Thu, 3 Jul 2008 17:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=0.913, 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 yAP4EfigrHsF for ; Thu, 3 Jul 2008 17:56:52 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id AD4033A6886 for ; Thu, 3 Jul 2008 17:56:52 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA03.westchester.pa.mail.comcast.net with comcast id lcpj1Z00D0mv7h05300N00; Fri, 04 Jul 2008 00:57:00 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA11.westchester.pa.mail.comcast.net with comcast id lcx01Z00D24Kx1C3Xcx0Ap; Fri, 04 Jul 2008 00:57:00 +0000 X-Authority-Analysis: v=1.0 c=1 a=Z1dMeT-byMiQo8WgZ1UA:9 a=eysXJ8BpFS2E7CEYfSQ0Hz_j1tcA:4 a=5FtdkfQUxfIA:10 From: "David B. Nelson" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> Date: Thu, 3 Jul 2008 20:57:08 -0400 Message-ID: <00f401c8dd70$e2a997a0$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjdYhKu4yqqF6deSFOHxzlMfkTQswADduyw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 19:58:55 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@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@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB2A3A6931 for ; 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 ; 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 ; 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" To: "'David B. Nelson'" , References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <00f401c8dd70$e2a997a0$6401a8c0@NEWTON603> Date: Fri, 4 Jul 2008 10:58:45 +0800 Message-ID: <024601c8dd81$e7c02c70$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjdYhKu4yqqF6deSFOHxzlMfkTQswADduywAAJnr5A= In-Reply-To: <00f401c8dd70$e2a997a0$6401a8c0@NEWTON603> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@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 80/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@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > Sent: Friday, July 04, 2008 8:57 AM > To: isms@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@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 19:59:13 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89863A695D; Thu, 3 Jul 2008 19:59:13 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A2E3A695D for ; Thu, 3 Jul 2008 19:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 tn1dugylNyR8 for ; Thu, 3 Jul 2008 19:59:12 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 2A65C3A68E5 for ; Thu, 3 Jul 2008 19:59:09 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 9D62A399A83; Thu, 3 Jul 2008 19:59:17 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=QsRuEu7Bpi7Yiz5vs1MBDc9HEcg=; b=bhalmfs/fsFFprs17Rtf2btIqerfdj3P+B9Zx+2X3w4KJmFLlNm+kYAtI9hXy1zwbcm5zuvj/IWHHO70GutNhMUnuT9Ipy4p047uFKbgAXbx4JqpNhYAh8fzBj/oX+RnDnWzINrM7J/yy6dx321uqNBFt4FRT2LdRrYC73F+8NI= Received: by wes.hardakers.net (Postfix, from userid 274) id 7C684399A84; Thu, 3 Jul 2008 19:59:17 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <00f401c8dd70$e2a997a0$6401a8c0@NEWTON603> Date: Thu, 03 Jul 2008 19:59:17 -0700 In-Reply-To: <00f401c8dd70$e2a997a0$6401a8c0@NEWTON603> (David B. Nelson's message of "Thu, 3 Jul 2008 20:57:08 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Thu, 3 Jul 2008 20:57:08 -0400, "David B. Nelson" said: DBN> Apparently the WG decided early on that, indeed, "any protected DBN> transport will do". I think what you're effectively suggesting is DBN> that we should *not* have a general TSM, but a series of xSMs, DBN> where "x" is a specific secure transport protocol. That was one of the suggestions that I said was possible if we wanted to solve the issue. I also said it was the one that I think was already decided against. The other one was a security name mapping. If you go back to my original post, I mentioned a few options and one of which was a mapping table in the DBN> KSM surely falls into that pattern. No, actually, it doesn't because it already was designed (in IETF history of the past) to be a separate security model and wasn't based on a tunnel transport and thus wasn't TSM based. So with KSM we already had the ability to separate out KSM from USM. I'm simply looking for a similar ability from future transport support. DBN> Personally, I think it's very late for that kind of revision. However, if DBN> it can be "hacked in" without much disruption, I see no fundamental DBN> objection to adding that feature. There wouldn't be little disruption (a minor wording change here or there and a MIB table). I'd be happy to supply the text and table for inclusion but I will wait until people think it's ok to consider including before committing resources to it. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 20:02:01 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7D63A6951; Thu, 3 Jul 2008 20:02:01 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFB23A6965 for ; Thu, 3 Jul 2008 20:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 4SgTyJg8+BOe for ; Thu, 3 Jul 2008 20:01:59 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 995D43A6951 for ; Thu, 3 Jul 2008 20:01:35 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 1BA7C399A83; Thu, 3 Jul 2008 20:01:44 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=wTWjvkYU84GyHx4TG81/RRXrBNc=; b=VQuTtf2DV/eZHeonPFw/uFUE8TJoSjBXplWlVEJeiIu1uqtd58xp6Juj0S7GqY7cQq1hSioA78BMe0RaBFkhxCNdhZcweoJb6cLmqKo1gt7IMQV1X2+bEICjmlso7LcvAop4uCg6LsooBRSiAmAUn+4RR0Xi7brNDdN3hdP376Y= Received: by wes.hardakers.net (Postfix, from userid 274) id 051E9399A84; Thu, 3 Jul 2008 20:01:44 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <00f401c8dd70$e2a997a0$6401a8c0@NEWTON603> <024601c8dd81$e7c02c70$51f780de@china.huawei.com> Date: Thu, 03 Jul 2008 20:01:43 -0700 In-Reply-To: <024601c8dd81$e7c02c70$51f780de@china.huawei.com> (David Harrington's message of "Fri, 4 Jul 2008 10:58:45 +0800") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Fri, 4 Jul 2008 10:58:45 +0800, "David Harrington" said: DH> I think the case Wes is concerned with happens 1% of the time, and DH> with thoughtful configuration can be reduced to 0.00763% of the time DH> (OK, I'll settle for 80/20). Then why was the VACM designed to operate differently based on the security protocol? Was that over-done and it should have been a simple vc/v3 enum instead? -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 20:59:05 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EAD03A695D; Thu, 3 Jul 2008 20:59:05 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49ECB3A6958 for ; Thu, 3 Jul 2008 20:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 BNgESsU+nSLc for ; Thu, 3 Jul 2008 20:59:04 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 66A7F3A695D for ; Thu, 3 Jul 2008 20:59:04 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id lSjp1Z01r0EPchoA20ej00; Fri, 04 Jul 2008 03:59:12 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id lfyv1Z0021m6Z1J8MfyzZW; Fri, 04 Jul 2008 03:59:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=mnySEfU0IRvuVEyUhtQA:9 a=DPHFEbn4kV9plqe05vf8wps8SHMA:4 a=86L1PGDMzkIA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><00f401c8dd70$e2a997a0$6401a8c0@NEWTON603><024601c8dd81$e7c02c70$51f780de@china.huawei.com> Date: Fri, 4 Jul 2008 11:58:54 +0800 Message-ID: <024a01c8dd8a$50370eb0$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjdglHslwclUg3+RLmkrB81w5Eu8QAAGvCA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Wes, I don't think VACM is designed to operate differently based on the security protocol. It is designed to operate differently based on the asserted securityLevel. Depending on the assertion made by the security model rather than an assessment of the presumed strength of the underlying security protocol was a deliberate decision of the SNMPv3 WG. In USM and SNMPv1 and SNMPv2c community-based security models, whether auth and priv are asserted is based on a binary decision (an auth and priv protocol have been specified or not), not the degree of trust in the underlying security protocol. (RFC3413 3.1 2) and 3), and RFC3584 5.2.1) In TSM, we accept the assertion made by the transport model. SSHTM makes its assertion based on "we have specified that the operator MUST configure for authpriv and to do otherwise is not compliant with this specification." It is up to the operator to ensure it is compliant. If an operator does not feel the underlying protocol really provides adequate authpriv support, then they should configure it to not be used with SNMP. I do not support TSM having a table to decide whether "auth" is "auth enough" or "priv" is "priv enough". dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Friday, July 04, 2008 11:02 AM > To: David Harrington > Cc: 'David B. Nelson'; isms@ietf.org > Subject: Re: [Isms] pre11 comments > > >>>>> On Fri, 4 Jul 2008 10:58:45 +0800, "David Harrington" > said: > > DH> I think the case Wes is concerned with happens 1% of the time, and > DH> with thoughtful configuration can be reduced to 0.00763% > of the time > DH> (OK, I'll settle for 80/20). > > Then why was the VACM designed to operate differently based on the > security protocol? Was that over-done and it should have > been a simple > vc/v3 enum instead? > > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 21:41:16 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68923A6A1F; Thu, 3 Jul 2008 21:41:16 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CCE53A6A1F for ; Thu, 3 Jul 2008 21:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 mwcNj6tbkmaQ for ; Thu, 3 Jul 2008 21:41:14 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 00BBF3A6920 for ; Thu, 3 Jul 2008 21:41:13 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 26B2C399A83; Thu, 3 Jul 2008 21:41:22 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=WLPFq3+BnjOGmVUdJh6+1tr4Gdw=; b=ZVMB5w79EKvpl6LrBtvCx3QdHT0dxqd3BW7Mhgy1yQooqafELwj9XnuDuIuHt3ylxDoSw/t3sYjVLQIv4o8ttFsLQ0QdBvP7e7AMdCpnr66OQTj6SygYJSFR42f5s+kXOsXTJ8e0kpvK+zjcVh9yBeZt2WC0P0aPmIoHCAKQA1g= Received: by wes.hardakers.net (Postfix, from userid 274) id 014C9399A84; Thu, 3 Jul 2008 21:41:21 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <00f401c8dd70$e2a997a0$6401a8c0@NEWTON603> <024601c8dd81$e7c02c70$51f780de@china.huawei.com> <024a01c8dd8a$50370eb0$51f780de@china.huawei.com> Date: Thu, 03 Jul 2008 21:41:21 -0700 In-Reply-To: <024a01c8dd8a$50370eb0$51f780de@china.huawei.com> (David Harrington's message of "Fri, 4 Jul 2008 11:58:54 +0800") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Fri, 4 Jul 2008 11:58:54 +0800, "David Harrington" 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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 3 22:40:40 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407503A6A62; Thu, 3 Jul 2008 22:40:40 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E775C3A6A59 for ; Thu, 3 Jul 2008 22:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, 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 zAqAnVkXXXYW for ; Thu, 3 Jul 2008 22:40:37 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id D47FA3A68A7 for ; Thu, 3 Jul 2008 22:40:37 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id lhUM1Z0010S2fkCA201900; Fri, 04 Jul 2008 05:40:46 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id lhgT1Z0081m6Z1J8VhgZyr; Fri, 04 Jul 2008 05:40:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=S37gv_Usj2LTEoCQku8A:9 a=OH9ai-mKWA2196N6LtIA:7 a=jiIJ0stx3hUV9khqtcpnod9pdyoA:4 a=86L1PGDMzkIA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><00f401c8dd70$e2a997a0$6401a8c0@NEWTON603><024601c8dd81$e7c02c70$51f780de@china.huawei.com><024a01c8dd8a$50370eb0$51f780de@china.huawei.com> Date: Fri, 4 Jul 2008 13:40:27 +0800 Message-ID: <025201c8dd98$801ed190$51f780de@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjdkDchGfRfxnF/SQmTwTP8xQiG6gABRdpA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org 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$B!#(B 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@hardakers.net] > Sent: Friday, July 04, 2008 12:41 PM > To: David Harrington > Cc: 'Wes Hardaker'; 'David B. Nelson'; isms@ietf.org > Subject: Re: [Isms] pre11 comments > > >>>>> On Fri, 4 Jul 2008 11:58:54 +0800, "David Harrington" > 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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jul 4 03:48:41 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3C03A6C33; Fri, 4 Jul 2008 03:48:41 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FA43A6C33 for ; Fri, 4 Jul 2008 03:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.688, 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 WvHNzNpbM8CH for ; Fri, 4 Jul 2008 03:48:38 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id B31813A6B6B for ; Fri, 4 Jul 2008 03:48:37 -0700 (PDT) X-Trace: 53295653/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.130.135 X-SBRS: None X-RemoteIP: 62.188.130.135 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAEKdbUg+vIKH/2dsb2JhbACDYId1pUED X-IronPort-AV: E=Sophos;i="4.30,302,1212361200"; d="scan'208";a="53295653" X-IP-Direction: IN Received: from 1cust135.tnt1.lnd4.gbr.da.uu.net (HELO allison) ([62.188.130.135]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Jul 2008 11:48:42 +0100 Message-ID: <001901c8ddba$5ff97a60$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <003e01c8dcd9$efd6b9e0$0601a8c0@allison> <015001c8dcfb$10e08230$51f780de@china.huawei.com> Date: Fri, 4 Jul 2008 11:41:19 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Isms] SSHTM ignores securityLevel was Re: pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; Sent: Thursday, July 03, 2008 12:52 PM Subject: RE: [Isms] pre11 comments > > So the SSHTM will never call openSession() and get an SSH session that > is not authpriv. > It will open one session for the domain/address/name and that will be > authpriv. If a user asks that a message be sent over SSH with > noAuthNoPriv, it will be sent over the one authpriv session associated > with the domain/address/name. If a user asks that a message be sent > over SSH with authNoPriv, it will be sent over the one authpriv > session. If a user asks that a message be sent over SSH with authpriv, > it will be sent over the one authpriv session. > > There will never be multiple sessions to differentiate between on the > basis of securityLevel. > Right, this is where we part company. I have always believed that there are good operational reasons for there to be multiple sessions. A change of securityLevel means a change of session and I have always seen that as a desirable feature eg that the mass of SNMP traffic is routine polling, noAuthNoPriv, while third-level support sometimes use authPriv to find and fix problems, and that it was important to keep them on separate TCP sessions, eg lest a getBulk of the 150,000 entry routing table on one delayed a poll on the other; or some such. The security aspects, of using a session of greater security than securityLevel, are fine, we agreed that long since, but I have always expected the traffic to be kept apart. (Of course, the transportAddress can and may provide separation of traffic) And when I read in the SSHTM I-D eg in s5.2 " 1) Determine the target index by extracting the transportDomain, transportAddress, securityName, and securityLevel from the tmStateReference. 2) Lookup the session in the Local Configuration Datastore using the target index" then I read that as saying that a change in securityLevel is a change in target index which leads to a different session [which I think is a good idea:-)]. If you are saying, use this 4-tuple as an index and for three parts use an exact match while the fourth must be less or equals, then I think that we need different words. Or if you are saying that the text means that the securityLevel is ignored, then again I find that a bit of a stretch. On a quick scan of the archives, I cannot see any discussion of this previously. So, I think you should get agreement that it is ok for the SSHTM to ignore the securityLevel in determing which session to use. In which case, I will go through the I-Ds and flag places where I believe that the English could be clearer; I suspect that there might be some such in tmsm e.g. s3.3 :-(. Tom Petch > > > > Tom Petch > > > > > The mapping happens at the transport model from the > > transport-specific > > > principal to the tmSecurityName. That mapping is obviously > > necessary. > > > > > > I see us adding options and complexity that I don't see operators > > > asking for, such as administratively definable transform > > selection. I > > > hope these really are needed. > > > > > > I agree that operators might want to disable SNMP use of a > transport > > > that is allowed on the device for other purposes. For that, a TSM > > > domain table with an enable/disable object might be appropriate. > > > However, since we specifically use an "snmp" subsystem, isn't it > > > likely that an SSH config can control whether the user can use the > > > snmp subsystem, much like they can decide to disable X11 > forwarding? > > > and even if they do get in, then VACM can prevent them from > > being able > > > to do anything snmp-related. So do we actually need to provide > this > > > control? > > > > > > David Harrington > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > dharrington@huawei.com > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@ietf.org > > > https://www.ietf.org/mailman/listinfo/isms > > > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jul 4 05:50:54 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1F13A69C0; Fri, 4 Jul 2008 05:50:54 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18FC3A682B for ; Fri, 4 Jul 2008 05:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.609, 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 EdufLhKnOY1N for ; Fri, 4 Jul 2008 05:50:52 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 7F2263A69C0 for ; Fri, 4 Jul 2008 05:50:52 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA03.westchester.pa.mail.comcast.net with comcast id lnba1Z00H1HzFnQ5305000; Fri, 04 Jul 2008 12:51:00 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA14.westchester.pa.mail.comcast.net with comcast id loqz1Z00B24Kx1C3aoqzhi; Fri, 04 Jul 2008 12:51:00 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZWAM9DwoIw7yUqL5hvAA:9 a=qreX3G-CR14KzSxpVxwA:7 a=RGVtamewaYERFlK0owgMDosgQHgA:4 a=5FtdkfQUxfIA:10 From: "David B. Nelson" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><00f401c8dd70$e2a997a0$6401a8c0@NEWTON603><024601c8dd81$e7c02c70$51f780de@china.huawei.com><024a01c8dd8a$50370eb0$51f780de@china.huawei.com> Date: Fri, 4 Jul 2008 08:51:07 -0400 Message-ID: <018a01c8ddd4$a0f2a180$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjdkDch06te1RzaQ/Krjf6NMxc6WwAQeUrQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker writes... > 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. Was that a conscious goal of the VACM design, or was that simply an unplanned outcome that some may have taken advantage of later? After all, if vacmSecurityName is supposed to be a model independent name, it seems odd to make it model dependent again in this fashion. > 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). I happen to think that level of simplification is probably a Good Idea (tm). I also think that the level of access control complexity (down to leaf node granularity) is more than 80% of operators find a valid use for. Sometimes having too many choices is a Bad Idea (tm). > The WG needs to make a decision whether we care about this or not. I personally don't care. I think we can solve the 80% problem by having a single TSM that is always "good enough" when correctly configured. BTW, correct configuration is *always* going to be a caveat for any security related solution. As Dave H. says, if there is a market demand for "Differentiated Services" TSM, one could always take the current work and spin up another document to describe it. I think (and this is my subjective opinion) that to be true to SNMPv3 architecture, you'd need to have multiple Security Models, each with its own name, rather than a single, parameterized Security Model that could export a pseudonym for the purpose of VACM mapping. At least for the sake of architectural description; the implementation could optimize by creating a single parameterized model, I suppose. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jul 4 06:04:18 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061D33A6B77; Fri, 4 Jul 2008 06:04:18 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9673A6B78 for ; Fri, 4 Jul 2008 06:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 NyAT19TwwKaD for ; Fri, 4 Jul 2008 06:04:16 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id D23603A6B43 for ; Fri, 4 Jul 2008 06:04:15 -0700 (PDT) Received: (qmail 60844 invoked from network); 4 Jul 2008 13:04:23 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jul 2008 13:04:23 -0000 From: "Bert Wijnen - IETF" To: "David B. Nelson" , Date: Fri, 4 Jul 2008 15:04:28 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <018a01c8ddd4$a0f2a180$6401a8c0@NEWTON603> Importance: Normal Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org W.r.t. David's question: > > Wes Hardaker writes... > > > 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. > > Was that a conscious goal of the VACM design, or was that simply an > unplanned outcome that some may have taken advantage of later? After all, > if vacmSecurityName is supposed to be a model independent name, > it seems odd to make it model dependent again in this fashion. > I remember the discussion very well, and I was opposed to see the vacmSecurityModel as one of the index objects. But in the end I was unable to convince (enough) others and so (rough) WG consensus was to indeed include it. > > 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). > > I happen to think that level of simplification is probably a Good > Idea (tm). > I also think that the level of access control complexity (down to > leaf node > granularity) is more than 80% of operators find a valid use for. > Sometimes having too many choices is a Bad Idea (tm). > I agree. In hindight, I think we overdesigned it which made it far more complex than needed. > > The WG needs to make a decision whether we care about this or not. > > I personally don't care. I think we can solve the 80% problem by having a > single TSM that is always "good enough" when correctly configured. BTW, > correct configuration is *always* going to be a caveat for any security > related solution. As Dave H. says, if there is a market demand for > "Differentiated Services" TSM, one could always take the current work and > spin up another document to describe it. > > I think (and this is my subjective opinion) that to be true to SNMPv3 > architecture, you'd need to have multiple Security Models, each > with its own name, rather than a single, parameterized Security Model that > could export a pseudonym for the purpose of VACM mapping. At least for the sake of > architectural description; the implementation could optimize by creating a > single parameterized model, I suppose. > Well, given my above comment, I guess you can understand that I am in favor of just using TSM (at least for now) as the security model, no matter what unerlying technology is being used. Bert _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 9 12:09:17 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B383A6A08; Wed, 9 Jul 2008 12:09:17 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2383A69FE for ; Tue, 1 Jul 2008 23:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=-1.992, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MANGLED_TOOL=2.3, MIME_QP_LONG_LINE=1.396] 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 3MH03F20Chic for ; Tue, 1 Jul 2008 23:54:35 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 784723A67B3 for ; Tue, 1 Jul 2008 23:54:35 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id kuYr1Z0040vp7WLA201N00; Wed, 02 Jul 2008 06:54:44 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id kuu61Z0021m6Z1J8RuuLkH; Wed, 02 Jul 2008 06:54:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZWqyAzHKKrUanf6KFTkA:9 a=AjcFJvYN8TTn-ktWm-wA:7 a=86qqqyzm3GNLI5po7PtI4CtAfgoA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 a=48vgC7mUAAAA:8 a=I0CVDw5ZAAAA:8 a=_InO6_KUeKD7fKliJyMA:9 a=-1hojd9B1ZZiASa7UYsA:7 a=K1wRiK5oXBby8LCq_kFOt50GbT0A:4 a=FvgKqOQ44qUA:10 a=oBKaSYGbyHAA:10 a=AVCpO1ehElwA:10 a=kLdjEiV55KYA:10 a=3BuQvuyjSHIA:10 a=3j06tXsvO8IA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=c5zHXd76wwQA:10 From: "David Harrington" To: Date: Wed, 2 Jul 2008 14:54:05 +0800 Message-ID: <002001c8dc10$772ffc00$51f780de@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0021_01C8DC53.85533C00" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjcEGqcQVX3jaqXTm68S2CXodewAw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailman-Approved-At: Wed, 09 Jul 2008 12:09:16 -0700 Subject: [Isms] pre11 draft X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C8DC53.85533C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am getting a chance to work on the secshell and tsm drafts today. To help everybody be on a similar page, here is the current state of the document. I have added a mib table for secshell showing a LCD approach. Some of this duplicates what I put into the TSM document, and some stuff will need to be removed from the TSM document. The two preXX documents are currently not in sync, and I know that. I have not completed the elements of procedure. I am running into some of the problems of translations and who knows what when that have been discussed recently; I think the information is available as needed, based on default transforms, but the devil is in the details. At this point in time, it is really important that if you want to discuss something about, say, securityName, that you point just where in the text you have concerns. I don't want to spend the limited time that I have to do this work on answering questions that come from poor generalization of the procedures. Walk through the specific elements of procedure to see what is known when. Do NOT mix up what is known for incoming and what is known for outgoing; walk through the psuedocode and be careful to not make assumptions about the contents of the fields. I see that as being a common problem in the WG discussions. I welcome text suggestions of the form, "in section x.x., paragraph 3, I suggest this rewording". I do not welcome suggested text of the form "well, let's discuss this big abstraction and I think the document should say something like yada-yada-yada wherever it is appropriate, and here are twenty paragraphs of related stuff that the editor should parse and figure out what should go where." David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0021_01C8DC53.85533C00 Content-Type: text/plain; name="draft-ietf-isms-secshell-pre11.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-secshell-pre11.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Standards Track J. Salowey=0A= Expires: January 2, 2009 Cisco Systems=0A= July 1, 2008=0A= =0A= =0A= Secure Shell Transport Model for SNMP=0A= draft-ietf-isms-secshell-11=0A= =0A= Status of This Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on January 2, 2009.=0A= =0A= Abstract=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 1]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 3=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 6=0A= 3. How SSHTM Fits into the Transport Subsystem . . . . . . . . . 7=0A= 3.1. Security Capabilities of this Model . . . . . . . . . . . 8=0A= 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 3.1.2. Message Authentication . . . . . . . . . . . . . . . . 9=0A= 3.1.3. Authentication Protocol Support . . . . . . . . . . . 10=0A= 3.1.4. Privacy Protocol Support . . . . . . . . . . . . . . . 10=0A= 3.1.5. Protection against Message Replay, Delay and=0A= Redirection . . . . . . . . . . . . . . . . . . . . . 10=0A= 3.1.6. SSH Subsystem . . . . . . . . . . . . . . . . . . . . 11=0A= 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 11=0A= 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 12=0A= 4. Passing Security Parameters . . . . . . . . . . . . . . . . . 12=0A= 4.1. tmStateReference . . . . . . . . . . . . . . . . . . . . . 12=0A= 4.2. tmSecurityName . . . . . . . . . . . . . . . . . . . . . . 14=0A= 4.3. tmSameSecurity . . . . . . . . . . . . . . . . . . . . . . 14=0A= 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 15=0A= 5.1. [TODO]Procedures for an Incoming Message . . . . . . . . . 15=0A= 5.2. [TODO]Procedures for an Outgoing Message . . . . . . . . . 16=0A= 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 18=0A= 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 20=0A= 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 20=0A= 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 20=0A= 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 20=0A= 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 21=0A= 6.3.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 21=0A= 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 21=0A= 8. Operational Considerations . . . . . . . . . . . . . . . . . . 30=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31=0A= 9.1. noAuthPriv . . . . . . . . . . . . . . . . . . . . . . . . 32=0A= 9.2. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 32=0A= 9.3. Skipping Public Key Verification . . . . . . . . . . . . . 32=0A= 9.4. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 33=0A= 9.5. MIB Module Security . . . . . . . . . . . . . . . . . . . 33=0A= 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34=0A= 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34=0A= 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34=0A= 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34=0A= 12.2. Informative References . . . . . . . . . . . . . . . . . . 36=0A= Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 37=0A= Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 38=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 2]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH) [RFC4251]=0A= within a transport subsystem [I-D.ietf-isms-tmsm]. The transport=0A= model specified in this memo is referred to as the Secure Shell=0A= Transport Model (SSHTM).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= It is important to understand the SNMP architecture [RFC3411] and the=0A= terminology of the architecture to understand where the Transport=0A= Model described in this memo fits into the architecture and interacts=0A= with other subsystems within the architecture.=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications. This is=0A= consistent with the IESG decision to not require the SNMPv3=0A= terminology be modified to match the usage of other non-SNMP=0A= specifications when SNMPv3 was advanced to Full Standard.=0A= =0A= Authentication in this document typically refers to the English=0A= meaning of "serving to prove the authenticity of" the message, not=0A= data source authentication or peer identity authentication.=0A= =0A= The terms "manager" and "agent" are not used in this document,=0A= because in the RFC 3411 architecture [RFC3411], all SNMP entities=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 3]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= have the capability of acting in either manager or agent or in both=0A= roles depending on the SNMP application types supported in the=0A= implementation. Where distinction is required, the application names=0A= of Command Generator, Command Responder, Notification Originator,=0A= Notification Receiver, and Proxy Forwarder are used. See "SNMP=0A= Applications" [RFC3413] for further information.=0A= =0A= Throughout this document, the terms "client" and "server" are used to=0A= refer to the two ends of the SSH transport connection. The client=0A= actively opens the SSH connection, and the server passively listens=0A= for the incoming SSH connection. Either SNMP entity may act as=0A= client or as server, as discussed further below.=0A= =0A= The User-Based Security Model (USM) [RFC3414] is a mandatory-to-=0A= implement Security Model in STD 62. While SSH and USM frequently=0A= refer to a user, the terminology preferred in RFC3411 [RFC3411] and=0A= in this memo is "principal". A principal is the "who" on whose=0A= behalf services are provided or processing takes place. A principal=0A= can be, among other things, an individual acting in a particular=0A= role; a set of individuals, with each acting in a particular role; an=0A= application or a set of applications, or a combination of these=0A= within an administrative domain.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= Sections requiring further editing are identified by [todo] markers=0A= in the text. Points requiring further WG research and discussion are=0A= identified by [discuss] markers in the text.=0A= =0A= Note to RFC Editor - if the previous paragraph and this note have not=0A= been removed, please send the document back to the editor to remove=0A= this.=0A= =0A= 1.3. Modularity=0A= =0A= The reader is expected to have read and understood the description of=0A= the SNMP architecture, as defined in [RFC3411], and the Transport=0A= Subsystem architecture extension specified in "Transport Subsystem=0A= for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm].=0A= =0A= This memo describes the Secure Shell Transport Model for SNMP, a=0A= specific SNMP transport model to be used within the SNMP transport=0A= subsystem to provide authentication, encryption, and integrity=0A= checking of SNMP messages.=0A= =0A= In keeping with the RFC 3411 design decision to use self-contained=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 4]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= documents, this document defines the elements of procedure and=0A= associated MIB module objects which are needed for processing the=0A= Secure Shell Transport Model for SNMP.=0A= =0A= This modularity of specification is not meant to be interpreted as=0A= imposing any specific requirements on implementation.=0A= =0A= 1.4. Motivation=0A= =0A= Version 3 of the Simple Network Management Protocol (SNMPv3) added=0A= security to the protocol. The User-based Security Model (USM)=0A= [RFC3414] was designed to be independent of other existing security=0A= infrastructures, to ensure it could function when third party=0A= authentication services were not available, such as in a broken=0A= network. As a result, USM utilizes a separate user and key=0A= management infrastructure. Operators have reported that deploying=0A= another user and key management infrastructure in order to use SNMPv3=0A= is a reason for not deploying SNMPv3.=0A= =0A= This memo describes a transport model that will make use of the=0A= existing and commonly deployed Secure Shell security infrastructure.=0A= This transport model is designed to meet the security and operational=0A= needs of network administrators, maximize usability in operational=0A= environments to achieve high deployment success and at the same time=0A= minimize implementation and deployment costs to minimize deployment=0A= time.=0A= =0A= This document addresses the requirement for the SSH client to=0A= authenticate the SSH server, for the SSH server to authenticate the=0A= SSH client, and describes how SNMP can make use of the authenticated=0A= identities in authorization policies for data access, in a manner=0A= that is independent of any specific access control model.=0A= =0A= This document addresses the requirement to utilize client=0A= authentication and key exchange methods which support different=0A= security infrastructures and provide different security properties.=0A= This document describes how to use client authentication as described=0A= in "SSH Authentication Protocol" [RFC4252]. The SSH Transport Model=0A= should work with any of the ssh-userauth methods including the=0A= "publickey", "password", "hostbased", "none", "keyboard-interactive",=0A= "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx"=0A= (see http://www.iana.org/assignments/ssh-parameters). The use of the=0A= "none" authentication method is NOT RECOMMENDED, as described in=0A= Security Considerations. Local accounts may be supported through the=0A= use of the publickey, hostbased or password methods. The password=0A= method allows for integration with deployed password infrastructure=0A= such as AAA servers using the RADIUS protocol [RFC2865]. The SSH=0A= Transport Model SHOULD be able to take advantage of future defined=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 5]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= ssh-userauth methods, such as those that might make use of X.509=0A= certificate credentials.=0A= =0A= It is desirable to use mechanisms that could unify the approach for=0A= administrative security for SNMPv3 and Command Line interfaces (CLI)=0A= and other management interfaces. The use of security services=0A= provided by Secure Shell is the approach commonly used for the CLI,=0A= and is the approach being adopted for use with NETCONF [RFC4742].=0A= This memo describes a method for invoking and running the SNMP=0A= protocol within a Secure Shell (SSH) session as an SSH subsystem.=0A= =0A= This memo describes how SNMP can be used within a Secure Shell (SSH)=0A= session, using the SSH connection protocol [RFC4254] over the SSH=0A= transport protocol, using SSH user-auth [RFC4252] for authentication.=0A= =0A= There are a number of challenges to be addressed to map Secure Shell=0A= authentication method parameters into the SNMP architecture so that=0A= SNMP continues to work without any surprises. These are discussed in=0A= detail below.=0A= =0A= 1.5. Constraints=0A= =0A= The design of this SNMP Transport Model is influenced by the=0A= following constraints:=0A= =0A= 1. In times of network stress, the transport protocol and its=0A= underlying security mechanisms SHOULD NOT depend upon the ready=0A= availability of other network services (e.g., Network Time=0A= Protocol (NTP) or AAA protocols).=0A= =0A= 2. When the network is not under stress, the transport model and its=0A= underlying security mechanisms MAY depend upon the ready=0A= availability of other network services.=0A= =0A= 3. It may not be possible for the transport model to determine when=0A= the network is under stress.=0A= =0A= 4. A transport model should require no changes to the SNMP=0A= architecture.=0A= =0A= 5. A transport model should require no changes to the underlying=0A= protocol.=0A= =0A= 2. The Secure Shell Protocol=0A= =0A= SSH is a protocol for secure remote login and other secure network=0A= services over an insecure network. It consists of three major=0A= protocol components, and add-on methods for user authentication:=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 6]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= o The Transport Layer Protocol [RFC4253] provides server=0A= authentication, and message confidentiality and integrity. It may=0A= optionally also provide compression. The transport layer will=0A= typically be run over a TCP/IP connection, but might also be used=0A= on top of any other reliable data stream.=0A= =0A= o The User Authentication Protocol [RFC4252] authenticates the=0A= client-side principal to the server. It runs over the transport=0A= layer protocol.=0A= =0A= o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel=0A= into several logical channels. It runs over the transport after=0A= successfully authenticating the principal.=0A= =0A= o Generic Message Exchange Authentication [RFC4256] is a general=0A= purpose authentication method for the SSH protocol, suitable for=0A= interactive authentications where the authentication data should=0A= be entered via a keyboard=0A= =0A= o Generic Security Service Application Program Interface (GSS-API)=0A= Authentication and Key Exchange for the Secure Shell (SSH)=0A= Protocol [RFC4462] describes methods for using the GSS-API for=0A= authentication and key exchange in SSH. It defines an SSH user=0A= authentication method that uses a specified GSS-API mechanism to=0A= authenticate a user, and a family of SSH key exchange methods that=0A= use GSS-API to authenticate a Diffie-Hellman key exchange.=0A= =0A= The client sends a service request once a secure transport layer=0A= connection has been established. A second service request is sent=0A= after client authentication is complete. This allows new protocols=0A= to be defined and coexist with the protocols listed above.=0A= =0A= The connection protocol provides channels that can be used for a wide=0A= range of purposes. Standard methods are provided for setting up=0A= secure interactive shell sessions and for forwarding ("tunneling")=0A= arbitrary TCP/IP ports and X11 connections.=0A= =0A= 3. How SSHTM Fits into the Transport Subsystem=0A= =0A= A transport model plugs into the Transport Subsystem=0A= [I-D.ietf-isms-tmsm]. The SSH Transport Model thus fits between the=0A= underlying SSH transport layer and the message dispatcher [RFC3411].=0A= =0A= The SSH Transport Model will establish a channel between itself and=0A= the SSH Transport Model of another SNMP engine. The sending=0A= transport model passes unencrypted messages from the dispatcher to=0A= SSH to be encrypted, and the receiving transport model accepts=0A= decrypted incoming messages from SSH and passes them to the=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 7]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= dispatcher.=0A= =0A= After an SSH Transport model channel is established, then SNMP=0A= messages can conceptually be sent through the channel from one SNMP=0A= message dispatcher to another SNMP message dispatcher. Multiple SNMP=0A= messages MAY be passed through the same channel.=0A= =0A= The SSH Transport Model of an SNMP engine will perform the=0A= translation between SSH-specific security parameters and SNMP-=0A= specific, model-independent parameters.=0A= =0A= 3.1. Security Capabilities of this Model=0A= =0A= 3.1.1. Threats=0A= =0A= The Secure Shell Transport Model provides protection against the=0A= threats identified by the RFC 3411 architecture [RFC3411]:=0A= =0A= 1. Message stream modification - SSH provides for verification that=0A= each received message has not been modified during its=0A= transmission through the network.=0A= =0A= 2. Information modification - SSH provides for verification that the=0A= contents of each received message has not been modified during=0A= its transmission through the network, data has not been altered=0A= or destroyed in an unauthorized manner, nor have data sequences=0A= been altered to an extent greater than can occur non-maliciously.=0A= =0A= 3. Masquerade - SSH provides for both verification of the identity=0A= of the SSH server and verification of the identity of the SSH=0A= client. SSH provides verification of the identity of the SSH=0A= server through the SSH Transport Protocol server authentication=0A= [RFC4253].=0A= =0A= 4. Verification of principal identity is important for use with the=0A= SNMP access control subsystem, to ensure that only authorized=0A= principals have access to potentially sensitive data. The SSH=0A= user identity is provided to the security model, so it can be=0A= used to map to an SNMP model-independent securityName for use=0A= with SNMP access control.=0A= =0A= 5. Authenticating both the SSH server and the SSH client ensures the=0A= authenticity of the SNMP engine that provides MIB data.=0A= Operators or management applications might act upon the data they=0A= receive (e.g., raise an alarm for an operator, modify the=0A= configuration of the device that sent the notification, modify=0A= the configuration of other devices in the network as the result=0A= of the notification, and so on), so it is important to know that=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 8]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= the provider of MIB data is authentic.=0A= =0A= 6. Disclosure - the SSH Transport Model provides that the contents=0A= of each received SNMP message are protected from disclosure to=0A= unauthorized persons.=0A= =0A= 7. Replay - SSH ensures that cryptographic keys established at the=0A= beginning of the SSH session and stored in the SSH session state=0A= are fresh new session keys generated for each session. These are=0A= used to authenticate and encrypt data, and to prevent replay=0A= across sessions. SSH uses sequence information to prevent the=0A= replay and reordering of messages within a session.=0A= =0A= 3.1.2. Message Authentication=0A= =0A= The RFC 3411 architecture recognizes three levels of security:=0A= =0A= - without authentication and without privacy (noAuthNoPriv)=0A= =0A= - with authentication but without privacy (authNoPriv)=0A= =0A= - with authentication and with privacy (authPriv)=0A= =0A= The Secure Shell protocol provides support for encryption and data=0A= integrity. While it is technically possible to support no=0A= authentication and no encryption in SSH it is NOT RECOMMENDED by=0A= [RFC4253].=0A= =0A= The SSH Transport Model determines from SSH the identity of the=0A= authenticated principal, and the type and address associated with an=0A= incoming message, and the SSH Transport Model provides this=0A= information to SSH for an outgoing message. The transport layer=0A= algorithms used to provide authentication, data integrity and=0A= encryption SHOULD NOT be exposed to the SSH Transport Model layer.=0A= The SNMPv3 WG deliberately avoided this and settled for an assertion=0A= by the security model that the requirements of securityLevel were met=0A= The SSH Transport Model has no mechanisms by which it can test=0A= whether an underlying SSH connection provides auth or priv, so the=0A= SSH Transport Model trusts that the underlying SSH connection has=0A= been properly configured to support authPriv security=0A= characteristics.=0A= =0A= The SSH Transport Model does not know about the algorithms or options=0A= to open SSH sessions that match different securityLevels. For=0A= interoperability of the trust assumptions between SNMP engines, an=0A= SSH Transport Model-compliant implementation MUST use an SSH=0A= connection that provides authentication, data integrity and=0A= encryption that meets the highest level of SNMP security (authPriv).=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 9]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Outgoing messages requested by SNMP applications and specified with a=0A= lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by the SSH=0A= Transport Model as authPriv securityLevel.=0A= =0A= The security protocols used in the Secure Shell Authentication=0A= Protocol [RFC4252] and the Secure Shell Transport Layer Protocol=0A= [RFC4253] are considered acceptably secure at the time of writing.=0A= However, the procedures allow for new authentication and privacy=0A= methods to be specified at a future time if the need arises.=0A= =0A= 3.1.3. Authentication Protocol Support=0A= =0A= The SSH Transport Model should support any server or client=0A= authentication mechanism supported by SSH. This includes the three=0A= authentication methods described in the SSH Authentication Protocol=0A= document [RFC4252] - publickey, password, and host-based - and=0A= keyboard interactive and others.=0A= =0A= The password authentication mechanism allows for integration with=0A= deployed password based infrastructure. It is possible to hand a=0A= password to a service such as RADIUS [RFC2865] or Diameter [RFC3588]=0A= for validation. The validation could be done using the user-name and=0A= user-password attributes. It is also possible to use a different=0A= password validation protocol such as CHAP [RFC1994] or digest=0A= authentication [RFC5090] to integrate with RADIUS or Diameter. At=0A= some point in the processing, these mechanisms require the password=0A= be made available as clear text on the device that is authenticating=0A= the password which might introduce threats to the authentication=0A= infrastructure. [DISCUSS: do we really need this paragraph?=0A= =0A= GSSKeyex [RFC4462] provides a framework for the addition of client=0A= authentication mechanisms which support different security=0A= infrastructures and provide different security properties.=0A= Additional authentication mechanisms, such as one that supports X.509=0A= certificates, may be added to SSH in the future.=0A= =0A= 3.1.4. Privacy Protocol Support=0A= =0A= The SSH transport model supports any privacy protocol used with SSH.=0A= [DISCUSS: The authentication support section goes into significant=0A= detail; should the same be done here?]=0A= =0A= 3.1.5. Protection against Message Replay, Delay and Redirection=0A= =0A= SSH uses sequence numbers and integrity checks to protect against=0A= replay and reordering of messages within a connection.=0A= =0A= SSH also provides protection against replay of entire sessions. In a=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 10]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= properly-implemented Diffie-Helman exchange, both sides will generate=0A= new random numbers for each exchange, which means the encryption and=0A= integrity keys will be distinct for every session.=0A= =0A= 3.1.6. SSH Subsystem=0A= =0A= This document describes the use of an SSH subsystem for SNMP to make=0A= SNMP usage distinct from other usages.=0A= =0A= SSH subsystems of type "snmp" are opened by the SSH Transport Model=0A= during the elements of procedure for an outgoing SNMP message. Since=0A= the sender of a message initiates the creation of an SSH session if=0A= needed, the SSH session will already exist for an incoming message or=0A= the incoming message would never reach the SSH Transport Model.=0A= [DISCUSS: If a notification originator opens a subsystem called=0A= "snmp" and a command generator opens a subsystem called "snmp", will=0A= that be confusing to SSH? ]=0A= =0A= Implementations MAY choose to instantiate SSH sessions in=0A= anticipation of outgoing messages. This approach might be useful to=0A= ensure that an SSH session to a given target can be established=0A= before it becomes important to send a message over the SSH session.=0A= Of course, there is no guarantee that a pre-established session will=0A= still be valid when needed.=0A= =0A= SSH sessions are uniquely identified within the SSH Transport Model=0A= by the combination of transportAddressType, transportAddress,=0A= securityName, and securityLevel associated with each session.=0A= =0A= 3.2. Security Parameter Passing=0A= =0A= For incoming messages, SSH-specific security parameters are=0A= translated by the transport model into security parameters=0A= independent of the transport and security models. The transport=0A= model accepts messages from the SSH subsystem, and records the=0A= transport-related and SSH-security-related information, including the=0A= authenticated identity, in a cache referenced by tmStateReference,=0A= and passes the WholeMsg and the tmStateReference to the dispatcher=0A= using the receiveMessage() ASI (Application Service Interface).=0A= =0A= For outgoing messages, the transport model takes input provided by=0A= the dispatcher in the sendMessage() ASI. The SSH Transport Model=0A= converts that information into suitable security parameters for SSH,=0A= establishes sessions as needed, and passes messages to the SSH=0A= subsystem for sending.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 11]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 3.3. Notifications and Proxy=0A= =0A= SSH connections may be initiated by command generators or by=0A= notification originators. Command generators are frequently operated=0A= by a human, but notification originators are usually unmanned=0A= automated processes. As a result, it may be necessary to provision=0A= authentication credentials on the SNMP engine containing the=0A= notification originator, or use a third party key provider such as=0A= Kerberos, so the engine can successfully authenticate to an engine=0A= containing a notification receiver.=0A= =0A= The targets to whom notifications should be sent is typically=0A= determined and configured by a network administrator. The SNMP-=0A= TARGET-MIB module [RFC3413] contains objects for defining management=0A= targets, including transport domains and addresses and security=0A= parameters, for applications such as notifications and proxy.=0A= =0A= For the SSH Transport Model, transport type and address are=0A= configured in the snmpTargetAddrTable, and the securityName, and=0A= securityLevel parameters are configured in the snmpTargetParamsTable.=0A= The default approach is for an administrator to statically=0A= preconfigure this information to identify the targets authorized to=0A= receive notifications or perform proxy.=0A= =0A= These MIB modules may be configured using SNMP or other=0A= implementation-dependent mechanisms, such as CLI scripting or loading=0A= a configuration file. It may be necessary to provide additional=0A= implementation-specific configuration of SSH parameters.=0A= =0A= 4. Passing Security Parameters=0A= =0A= For the SSH Transport Model, the session state needs to be maintained=0A= using tmStateReference. RFC3411 discusses a securityStateReference,=0A= which is not accessible to the Transport Subsystem.=0A= =0A= 4.1. tmStateReference=0A= =0A= Upon opening each SSH connection, the SSH Transport Model stores=0A= model- and mechanism-specific information about the connection in a=0A= cache, referenced by tmStateReference.=0A= =0A= For interoperability with Security Model designs, the state=0A= referenced by tmStateReference MUST include the following fields=0A= (with sample values). See the Elements of Procedure for detailed=0A= processing instructions on the use of these fields by the SSH=0A= Transport Model.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 12]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= tmTransport =3D snmpSSHDomain=0A= =0A= tmAddress =3D an snmpSSHAddress=0A= =0A= tmRequestedSecurityLevel =3D ["noAuthNoPriv" | "authNoPriv" |=0A= "authPriv" ]=0A= =0A= tmTransportSecurityLevel =3D "authPriv"=0A= =0A= tmSecurityName =3D the principal name [to be] authenticated by SSH.=0A= See the section on tmSecurityName below.=0A= =0A= tmSameSecurity =3D true or false, depending on whether the Security=0A= Model requires that an outgoing response be sent using the same=0A= security parameters as were used for the incoming request or for=0A= any other security-model-dependent reason. See the section on=0A= tmSameSecurity below.=0A= =0A= =0A= =0A= The state referenced by tmStateReference for an SSH Transport Model=0A= should also contain an implementation-dependent identifier (e.g.,=0A= tmSessionID) that can be used to determine whether the SSH session=0A= available for sending an outgoing message is the same SSH session as=0A= was used when receiving the corresponding incoming message.=0A= =0A= The tmStateReference is used to pass references containing the=0A= appropriate SSH session information from the transport model for=0A= subsequent processing.=0A= =0A= The state referenced by tmStateReference may be saved across multiple=0A= messages in a Local Configuration Datastore (sshtmLCDTable).=0A= =0A= A Transport Model will maintain any mapping between transport-=0A= specific security parameters and tmTransportSecurityLevel and=0A= tmSecurityName, and will verify for outgoing messages that the=0A= transport-provided security is at least as strong as=0A= tmRequestedSecurityLevel..=0A= =0A= The SSH Transport Model implementation has the responsibility for=0A= explicitly releasing the complete tmStateReference and associated=0A= information when a session is closed.=0A= =0A= Since the contents of a cache are meaningful only within an=0A= implementation, and not on-the-wire, the format of the cache and the=0A= sshtmLCDTable are implementation-specific.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 13]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 4.2. tmSecurityName=0A= =0A= How the SSH identity is extracted from the SSH layer is=0A= implementation-dependent. How the SSH identity is mapped to a=0A= tmSecurityName should be administratively configurable.=0A= =0A= [TODO: standardize some dynamic mechanisms for SSHTM, per auth-=0A= protocol, such as user-auth, host-auth, etc. Make the list of=0A= authProtocols expandable, and provide default algorithms.] [DISCUSS:=0A= this cannot be implementation-dependent. It used to identify the=0A= layer 8 principal for use in such things as logging and for access=0A= control policy assignment. it must generate a predictable=0A= securityName representing the principal, regardless of the=0A= authentication mechanism. USM provides this by pre-configuration of=0A= the mapping of the auth protocol and auth-specific credentials to a=0A= securityName, in the usmUserTable. We MUST have the similar mapping,=0A= preferably done dynamically rather than statically. Therefore either=0A= the dynamic mapping algorithm MUST be standardized. or we MUST have a=0A= static mapping.]=0A= =0A= tmSecurityName is a human-readable name in SnmpAdminString format=0A= that is mapped from the identity that has been successfully=0A= authenticated by SSH. By default, tmSecurityName is determined from=0A= the value of the user name field of the SSH_MSG_USERAUTH_REQUEST=0A= message for which a SSH_MSG_USERAUTH_SUCCESS has been received.=0A= =0A= As described in RFC4252 section 5, all authentication requests,=0A= regardless of authentication mechanism, MUST use the same message=0A= format, which includes a byte to indicate SSH_MSG_USERAUTH_REQUEST,=0A= and a user name field. How the authenticated user name is made=0A= available to the SNMP implementation is SSH-implementation dependent.=0A= =0A= 4.3. tmSameSecurity=0A= =0A= If a Secure Shell transport session is closed between the time a=0A= request message is received and the corresponding response message is=0A= sent, then the response message MUST be discarded, even if a new SSH=0A= session has been established. The SSH Transport Model does not know=0A= whether a message contains a request or response (at least=0A= architecturally, this is not available to the transport model;=0A= implementations may choose to make this available for simplicity.)=0A= =0A= Each Security Model that supports the tmStateReference cache will=0A= pass a tmSameSecurity parameter in the tmStateReference cache for=0A= outgoing messages to indicate whether the same security MUST be used=0A= for the outgoing message as was used for the corresponding incoming=0A= message (e.g., a request-response pair). The tmStateReference for=0A= the Secure Shell Transport Model may also include an existing SSH-=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 14]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= specific transport session identifier in an implementation-dependent=0A= format.=0A= =0A= If the tmSameSecurity is indicated, but the session identified in the=0A= tmStateReference does not match the current established SSH transport=0A= session, i.e., it is not the same SSH security session, the message=0A= MUST be discarded, and the dispatcher should be notified that the=0A= sending of the message failed.=0A= =0A= 5. Elements of Procedure=0A= =0A= Abstract service interfaces have been defined by RFC 3411 to describe=0A= the conceptual data flows between the various subsystems within an=0A= SNMP entity. The Secure Shell Transport Model uses some of these=0A= conceptual data flows when communicating between subsystems. These=0A= RFC 3411-defined data flows are referred to here as public=0A= interfaces.=0A= =0A= To simplify the elements of procedure, the release of state=0A= information is not always explicitly specified. As a general rule,=0A= if state information is available when a message gets discarded, the=0A= message-state information should also be released, and if state=0A= information is available when a session is closed, the session state=0A= information should also be released.=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected. ContextEngineID and contextName are not accessible to=0A= Transport Models, so contextEngineID is set to the local value of=0A= snmpEngineID, and contextName is set to the default context for error=0A= counters.=0A= =0A= 5.1. [TODO]Procedures for an Incoming Message=0A= =0A= 1) The SSH Transport Model queries the SSH engine, in an=0A= implementation-dependent manner, to determine the transportAddress,=0A= and the principal name authenticated by SSH.=0A= =0A= By default, the principal name is the value of the user name field of=0A= the SSH_MSG_USERAUTH_REQUEST message for which a=0A= SSH_MSG_USERAUTH_SUCCESS has been received. How this name is=0A= extracted from the SSH environment is implementation-dependent.=0A= =0A= 2) Using the sshtmLCDPolicy, calculate a corresponding securityName=0A= value. Determine if there is a row in the sshtmLCDTable with the=0A= transport address and an sshtmLCDSecurityName that matches the=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 15]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= calculated securityName value.=0A= =0A= 3) If one does not exist, create an entry in the sshtmLCDTable:=0A= =0A= sshtmTransportAddress =3D transport address=0A= =0A= sshtmLCDSecurityName =3D calculated securityName=0A= =0A= sshtmLCDName=3Dthe SSH principal=0A= =0A= sshtmStorageType=3Dvolatile=0A= =0A= sshtmRowStatus=3DcreateAndGo=0A= =0A= 4) Create a tmStateReference cache for subsequent reference to the=0A= information.=0A= =0A= tmTransportDomain =3D snmpSSHDomain=0A= =0A= tmTransportAddress =3D sshtmLCDTransportAddress=0A= =0A= tmSecurityLevel =3D "authPriv"=0A= =0A= tmSecurityName =3D sshtmLCDSecurityName=0A= =0A= tmSessionID =3D an implementation-dependent value that can be used=0A= to detect when a session has closed and been replaced by another=0A= session.=0A= =0A= Then the Transport model passes the message to the Dispatcher using=0A= the following ASI:=0A= =0A= statusInformation =3D=0A= receiveMessage(=0A= IN transportDomain -- snmpSSHDomain=0A= IN transportAddress -- address for the received message=0A= IN wholeMessage -- the whole SNMP message from SSH=0A= IN wholeMessageLength -- the length of the SNMP message=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= 5.2. [TODO]Procedures for an Outgoing Message=0A= =0A= The Dispatcher passes the information to the Transport Model using=0A= the ASI defined in the transport subsystem:=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 16]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= statusInformation =3D=0A= sendMessage(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN outgoingMessage -- the message to send=0A= IN outgoingMessageLength -- its length=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= The SSH Transport Model performs the following tasks:=0A= =0A= 1) Extract the tmTransportDomain, tmTransportAddress,=0A= tmSecurityName, tmSecurityLevel, tmSameSecurity, and tmSessionID=0A= from the tmStateReference.=0A= =0A= 2) Using tmTransportAddress and tmSecurityName, determine if a=0A= corresponding row exists in the sshtmLCDTable.=0A= =0A= 3) If there is a corresponding row, and tmSameSecurity is true,=0A= and tmSessionID does not match sshtmSessionID, then increment the=0A= sshtmSessionNoAvailableSessions counter, discard the message and=0A= return the error indication in the statusInformation. Processing=0A= of this message stops.=0A= =0A= 4) If there is no corresponding row, then create a row in the=0A= sshtmLCDTable:=0A= =0A= sshtmLCDTransportAddress=3DtmTransportAddress=0A= =0A= sshtmLCDSecurityName =3D tmSecurityName=0A= =0A= Using the sshtmLCDPolicy, calculate a corresponding=0A= sshtmLCDName value.=0A= =0A= 4a) Call openSession()=0A= =0A= 4b) If an error is returned from OpenSession(), then discard the=0A= message, delete the row, and return the error indication returned=0A= by OpenSession() in the statusInformation.=0A= =0A= 4b) If openSession() is successful, then set sshtmLCDSessionID to=0A= the value of sshtmLCDSpinLock and increment sshtmLCDSpinLock.=0A= =0A= 5) Extract any implementation-specific parameters from the=0A= sshtmLCDTable=0A= =0A= 6) Pass the wholeMessage to SSH for encapsulation as data in an=0A= SSH message.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 17]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 5.3. Establishing a Session=0A= =0A= [TODO]The Secure Shell Transport Model provides the following=0A= application service interface (ASI) to describe the data passed=0A= between the Transport Model and the SSH service. It is an=0A= implementation decision how such data is passed.=0A= =0A= statusInformation =3D=0A= openSession(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN maxMessageSize -- of the sending SNMP entity=0A= OUT tmStateReference -- (NEW) transport info=0A= )=0A= =0A= =0A= The following describes the procedure to follow to establish a=0A= session between a client and server to run SNMP over SSH. This=0A= process is followed by any SNMP engine establishing a session for=0A= subsequent use.=0A= =0A= This will be done automatically for an SNMP application that=0A= initiates a transaction, such as a Command Generator or a=0A= Notification Originator or a Proxy Forwarder.=0A= =0A= 1) Using destTransportDomain and destTransportAddress, the client=0A= will establish an SSH transport connection using the SSH transport=0A= protocol, authenticate the server, and exchange keys for message=0A= integrity and encryption. The parameters of the transport connection=0A= and the credentials used to authenticate are provided in an=0A= implementation-dependent manner.=0A= =0A= If the attempt to establish a connection is unsuccessful, or server=0A= authentication fails, then sshtmSessionOpenErrors is incremented, and=0A= an openSession error indication is returned, and openSession=0A= processing stops.=0A= =0A= 2) The provided transport domain, transport address, securityName and=0A= securityLevel are used to lookup an associated entry in the Local=0A= Configuration Datastore (sshtmLCDTable). Any model-specific=0A= information concerning the principal at the destination is extracted.=0A= This step allows preconfiguration of model-specific principals mapped=0A= to the transport/name/level, for example, for sending notifications.=0A= =0A= In an implementation-specific manner, pass the username extracted=0A= from the sshtmLCDTable to the SSH layer. [TODO: this may need to be=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 18]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= standardized.]=0A= =0A= 3)The client will then invoke an SSH authentications service to=0A= authenticate the user, such as that described in the SSH=0A= authentication protocol [RFC4252]. The credentials used to=0A= authenticate are provided in an implementation-dependent manner.=0A= =0A= If the authentication is unsuccessful, then the transport connection=0A= is closed, tmStateReference is released, the message is discarded,=0A= the sshtmSessionUserAuthFailures counter is incremented, an error=0A= indication is returned to the calling module, and processing stops=0A= for this message.=0A= =0A= 4) Once the principal has been successfully authenticated, the client=0A= will invoke the "ssh- connection" service, also known as the SSH=0A= connection protocol [RFC4254].=0A= =0A= 5) After the ssh-connection service is established, the client will=0A= request a channel of type "session" in an implementation-dependent=0A= manner. If unsuccessful, the sshtmSessionChannelOpenFailures counter=0A= is incremented, an error indication is returned to the calling=0A= module, and processing stops for this message.=0A= =0A= 6) If successful, this will result in an SSH session. The=0A= destTransportDomain and the destTransportAddress, plus any=0A= implementation-dependent identifier for the channel should be=0A= retained so they can be added to the sshtmLCDTable for subsequent=0A= use.=0A= =0A= 7) Once the SSH session has been established, the client will invoke=0A= SNMP as an SSH subsystem, as indicated in the "subsystem" parameter.=0A= =0A= In order to allow SNMP traffic to be easily identified and filtered=0A= by firewalls and other network devices, servers associated with SNMP=0A= entities using the Secure Shell Transport Model MUST default to=0A= providing access to the "SNMP" SSH subsystem if the SSH session is=0A= established using the IANA-assigned TCP port. Servers SHOULD be=0A= configurable to allow access to the SNMP SSH subsystem over other=0A= ports.=0A= =0A= 8) Create an entry in a Local Configuration Datastore containing the=0A= provided transportDomain, transportAddress, securityName,=0A= securityLevel, and SSH-specific parameters and create a=0A= tmStateReference to reference the entry.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 19]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 5.4. Closing a Session=0A= =0A= The Secure Shell Transport Model provides the following ASI to close=0A= a session:=0A= =0A= statusInformation =3D=0A= closeSession(=0A= IN tmStateReference -- transport info=0A= )=0A= =0A= =0A= =0A= The following describes the procedure to follow to close a session=0A= between a client and sever . This process is followed by any SNMP=0A= engine closing the corresponding SNMP session.=0A= =0A= 1) Extract the transportDomain, transportAddress, securityName,=0A= and securityLevel from the tmStateReference.=0A= =0A= 2) Lookup the session in the Local Configuration Datastore using=0A= the target index=0A= =0A= 3) If there is no session open associated with the target index,=0A= then closeSession processing is completed.=0A= =0A= 4) Extract any implementation-specific parameters from the=0A= sshtmLCDTable=0A= =0A= 5) Have SSH close the specified session.=0A= =0A= 6. MIB Module Overview=0A= =0A= This MIB module provides management of the Secure Shell Transport=0A= Model. It defines some needed textual conventions, and some=0A= statistics.=0A= =0A= 6.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= 6.2. Textual Conventions=0A= =0A= Generic and Common Textual Conventions used in this document can be=0A= found summarized at http://www.ops.ietf.org/mib-common-tcs.html=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 20]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 6.3. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing the SSH Transport Model. In particular, it=0A= is assumed that an entity implementing the SSHTM-MIB will implement=0A= the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411] and the=0A= SNMP-TRANSPORT-MIB [I-D.ietf-isms-tmsm].=0A= =0A= This MIB module is for managing SSH Transport Model information.=0A= This MIB module models a sample Local Configuration Datastore.=0A= =0A= 6.3.1. MIB Modules Required for IMPORTS=0A= =0A= The following MIB module imports items from [RFC2578], [RFC2579],=0A= [RFC2580].=0A= =0A= This MIB module also references [RFC3490] and [RFC3986]=0A= =0A= 7. MIB Module Definition=0A= =0A= =0A= SSHTM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= OBJECT-IDENTITY, mib-2, snmpDomains,=0A= Counter32=0A= FROM SNMPv2-SMI=0A= TEXTUAL-CONVENTION=0A= FROM SNMPv2-TC=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= ;=0A= =0A= sshtmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200710140000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 21]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= quittek@netlab.nec.de=0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Co-editors:=0A= David Harrington=0A= Huawei Technologies USA=0A= 1700 Alma Drive=0A= Plano Texas 75075=0A= USA=0A= +1 603-436-8634=0A= ietfdbh@comcast.net=0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= =0A= =0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= jsalowey@cisco.com=0A= "=0A= DESCRIPTION "The Secure Shell Transport Model MIB=0A= =0A= Copyright (C) The IETF Trust (2007). This=0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200710140000Z"=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- ---------------------------------------------------------- --=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 22]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= -- subtrees in the SNMP-SSH-TM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= sshtmNotifications OBJECT IDENTIFIER ::=3D { sshtmMIB 0 }=0A= sshtmObjects OBJECT IDENTIFIER ::=3D { sshtmMIB 1 }=0A= sshtmConformance OBJECT IDENTIFIER ::=3D { sshtmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= snmpSSHDomain OBJECT-IDENTITY=0A= STATUS current=0A= DESCRIPTION=0A= "The SNMP over SSH transport domain. The corresponding transport=0A= address is of type SnmpSSHAddress.=0A= =0A= When an SNMP entity uses the snmpSSHDomain transport=0A= model, it must be capable of accepting messages up to=0A= and including 8192 octets in size. Implementation of=0A= larger values is encouraged whenever possible."=0A= ::=3D { snmpDomains yy }=0A= =0A= =0A= -- RFC Ed.: replace yy with IANA-assigned number and=0A= -- remove this note=0A= =0A= SnmpSSHAddress ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "1a"=0A= STATUS current=0A= DESCRIPTION=0A= "Represents either a hostname with a port number or an IP=0A= address with a port number.=0A= =0A= The hostname must be encoded in ASCII, as specified in=0A= RFC3490 (Internationalizing Domain Names in Applications)=0A= followed by a colon ':' (ASCII character 0x3A) and a=0A= decimal port number in ASCII. The name SHOULD be fully=0A= qualified whenever possible.=0A= =0A= An IPv4 address must be a dotted decimal format followed=0A= by a colon ':' (ASCII character 0x3A) and a decimal port=0A= number in ASCII.=0A= =0A= An IPv6 address must be a colon separated format,=0A= surrounded by brackets, followed by a colon ':' (ASCII=0A= character 0x3A) and a decimal port number in ASCII.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 23]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Values of this textual convention may not be directly useable=0A= as transport-layer addressing information, and may require=0A= runtime resolution. As such, applications that write them=0A= must be prepared for handling errors if such values are=0A= not supported, or cannot be resolved (if resolution occurs=0A= at the time of the management operation).=0A= =0A= The DESCRIPTION clause of TransportAddress objects that may=0A= have snmpSSHAddress values must fully describe how (and=0A= when) such names are to be resolved to IP addresses and vice=0A= versa.=0A= =0A= This textual convention SHOULD NOT be used directly in=0A= object definitions since it restricts addresses to a=0A= specific format. However, if it is used, it MAY be used=0A= either on its own or in conjunction with=0A= TransportAddressType or TransportDomain as a pair.=0A= =0A= When this textual convention is used as a syntax of an=0A= index object, there may be issues with the limit of 128=0A= sub-identifiers specified in SMIv2, STD 58. It is=0A= RECOMMENDED that all MIB documents using this textual=0A= convention make explicit any limitations on index=0A= component lengths that management software must observe.=0A= This may be done either by including SIZE constraints on=0A= the index components or by specifying applicable=0A= constraints in the conceptual row DESCRIPTION clause or=0A= in the surrounding documentation.=0A= "=0A= REFERENCE=0A= "RFC3896, Uniform Resource Identifier (URI): Generic Syntax"=0A= SYNTAX OCTET STRING (SIZE (1..255))=0A= =0A= =0A= -- The sshtmSession Group=0A= =0A= sshtmSession OBJECT IDENTIFIER ::=3D { sshtmObjects 1 }=0A= sshtmLCD OBJECT IDENTIFIER ::=3D { sshtmObjects 2 }=0A= =0A= sshtmSessionOpens OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request has been=0A= executed, whether it succeeded or failed.=0A= "=0A= ::=3D { sshtmSession 1 }=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 24]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= sshtmSessionCloses OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times a closeSession() request has been=0A= executed, whether it succeeded or failed.=0A= "=0A= ::=3D { sshtmSession 2 }=0A= =0A= sshtmSessionOpenErrors OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a Session, for any reason.=0A= "=0A= ::=3D { sshtmSession 3 }=0A= =0A= sshtmSessionUserAuthFailures OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed due to user authentication failures.=0A= "=0A= ::=3D { sshtmSession 4 }=0A= =0A= sshtmSessionChannelOpenFailures OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed due to channel open failures.=0A= "=0A= ::=3D { sshtmSession 5 }=0A= =0A= sshtmSessionNoAvailableSessions OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an outgoing message=0A= was dropped because the same=0A= session was no longer available.=0A= "=0A= ::=3D { sshtmSession 6 }=0A= =0A= -- The table of users for the Transport Security Model=0A= -- This table can support users of multiple transport models=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 25]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= sshtmLCDSpinLock OBJECT-TYPE=0A= SYNTAX TestAndIncr=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION "An advisory lock used to allow several cooperating=0A= Command Generator Applications to coordinate their=0A= use of facilities to alter the sshtmLCDTable.=0A= "=0A= ::=3D { sshtmLCD 1 }=0A= =0A= -- The transform for the SSH Transport Model=0A= =0A= sshtmLCDTransformPolicy OBJECT-TYPE=0A= SYNTAX INTEGER { default(1),=0A= private(2)=0A= }=0A= =0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION=0A= "The policy that should be used to perform transforms=0A= between the transport specific identity and=0A= tmSecurityName.=0A= =0A= This transform is provided in case multiple transport models=0A= generate the same securityName.=0A= =0A= default (1) - for incoming messages, the value passed in=0A= the user name field of SSH user_auth is assigned=0A= to both sshtmLCDSecurityName and sshtmLCDName.=0A= For outgoing messages, the value passed in tmSecurityName=0A= is assigned to both sshtmLCDSecurityName and=0A= sshtmLCDName.=0A= =0A= private (2) - use an implementation-specific mapping=0A= algorithm for the transform. If the algorithm does not yield=0A= a mapping, no entry should be created for the identity in=0A= the sshtmLCDTable. It is implementation-dependent=0A= whether a private algorithm is supported.=0A= "=0A= DEFVAL { default }=0A= ::=3D { sshtmLCD 2 }=0A= =0A= sshtmLCDTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF sshtmLCDEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The table of users configured in the SSH=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 26]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Transport Model Local Configuration Datastore (LCD).=0A= =0A= Rows in this table can be instantiated when an=0A= authenticated identity is passed to the transport model=0A= from SSH, and they can be instantiated by a command=0A= generator.=0A= =0A= To instantiate a new row in this table, the=0A= sshtmLCDSpinLock should be used to prevent conflicts.=0A= =0A= 1) GET(sshtmLCDSpinLock.0) and save in sValue.=0A= =0A= 2) SET(sshtmLCDSpinLock.0=3DsValue,=0A= sshtmLCDTransportAddress=3D(desired value),=0A= sshtmLCDSecurityName=3D(desired value),=0A= sshtmLCDName=3D(desired value),=0A= sshtmLCDSessionID=3DsValue,=0A= sshtmLCDStorageType=3D(desired value),=0A= sshtmLCDStatus=3DcreateAndGo)=0A= "=0A= ::=3D { sshtmLCD 3 }=0A= =0A= sshtmLCDEntry OBJECT-TYPE=0A= SYNTAX sshtmLCDEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A user configured in the Local=0A= Configuration Datastore (LCD) for the SSH=0A= Transport Model.=0A= =0A= To maintain modularity of design, and to avoid=0A= side-effects, only the SSH Transport Model=0A= (or a SET operation) should modify this table.=0A= "=0A= INDEX { sshtmLCDTransportAddress,=0A= sshtmLCDSecurityName=0A= }=0A= ::=3D { sshtmLCDTable 1 }=0A= =0A= sshtmLCDEntry ::=3D SEQUENCE=0A= {=0A= sshtmLCDTransportAddress TransportAddress,=0A= sshtmLCDSecurityName SnmpAdminString,=0A= sshtmLCDName SnmpAdminString,=0A= sshtmLCDSessionID Integer32=0A= sshtmLCDStorageType StorageType,=0A= sshtmLCDRowStatus RowStatus=0A= }=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 27]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= sshtmLCDTransportAddress OBJECT-TYPE=0A= SYNTAX TransportAddress=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "This object contains a transport address.=0A= "=0A= ::=3D { sshtmLCDEntry 2 }=0A= =0A= sshtmLCDSecurityName OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A human readable string representing the user.=0A= This value is passed in tmSecurityName.=0A= =0A= The default transformation of the SSH user name to=0A= tmSecurityName and vice versa is the identity function=0A= so the sshtmLCDSecurityName is usually the same as the=0A= sshtmLCDName.=0A= "=0A= ::=3D { sshtmLCDEntry 3 }=0A= =0A= sshtmLCDName OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "A human readable string used to determine, in an=0A= implementation-dependent manner, which SSH=0A= credentials are used during authentication of the=0A= prinicipal.=0A= =0A= By default, this is the SSH user name.=0A= "=0A= ::=3D { sshtmLCDEntry 5 }=0A= =0A= sshtmLCDStorageType OBJECT-TYPE=0A= SYNTAX StorageType=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "The storage type for this conceptual row.=0A= =0A= Conceptual rows having the value readOnly, permanent,=0A= or nonVolatile must persist across reinitializations of=0A= the management subsystem.=0A= =0A= Conceptual rows having the value 'volatile' must not=0A= persist across reinitializations of the management=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 28]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= subsystem.=0A= =0A= It is an implementation issue to decide if a SET for=0A= a readOnly or permanent row is accepted at all. In=0A= some contexts this may make sense, in others it may=0A= not. If a SET for a readOnly or permanent row is not=0A= accepted at all, then a 'wrongValue' error must be=0A= returned.=0A= "=0A= DEFVAL { volatile }=0A= ::=3D { sshtmLCDEntry 6 }=0A= =0A= sshtmLCDRowStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "The status of this conceptual row.=0A= =0A= Until instances of all corresponding columns are=0A= appropriately configured, the value of the=0A= corresponding instance of sshtmLCDStatus=0A= is 'notReady'.=0A= =0A= The sshtmLCDName value should only be=0A= changed when the value of this object=0A= is 'active'.=0A= "=0A= ::=3D { sshtmLCDEntry 7 }=0A= =0A= -- ************************************************=0A= -- sshtmMIB - Conformance Information=0A= -- ************************************************=0A= =0A= sshtmCompliances OBJECT IDENTIFIER ::=3D { sshtmConformance 1 }=0A= =0A= sshtmGroups OBJECT IDENTIFIER ::=3D { sshtmConformance 2 }=0A= =0A= -- ************************************************=0A= -- Compliance statements=0A= -- ************************************************=0A= =0A= sshtmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for SNMP engines that support the=0A= SNMP-SSH-TM-MIB"=0A= MODULE=0A= MANDATORY-GROUPS { sshtmGroup }=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 29]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= ::=3D { sshtmCompliances 1 }=0A= =0A= -- ************************************************=0A= -- Units of conformance=0A= -- ************************************************=0A= sshtmGroup OBJECT-GROUP=0A= OBJECTS {=0A= sshtmSessionOpens,=0A= sshtmSessionCloses,=0A= sshtmSessionOpenErrors,=0A= sshtmSessionUserAuthFailures,=0A= sshtmSessionChannelOpenFailures,=0A= sshtmSessionNoAvailableSessions,=0A= sshtmLCDSpinLock,=0A= sshtmLCDTransportAddress,=0A= sshtmLCDSecurityName,=0A= sshtmLCDName,=0A= sshtmLCDStorageType,=0A= sshtmLCDRowStatus=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining=0A= information of an SNMP engine which implements the=0A= SNMP Secure Shell Transport Model.=0A= "=0A= =0A= =0A= ::=3D { sshtmGroups 2 }=0A= =0A= =0A= END=0A= =0A= =0A= 8. Operational Considerations=0A= =0A= The SSH Transport Model will likely not work in conditions where=0A= access to the CLI has stopped working. In situations where SNMP=0A= access has to work when the CLI has stopped working, a UDP transport=0A= model should be considered instead of the SSH Transport Model.=0A= =0A= The SSH Transport Model defines two well-known default ports, one for=0A= request/response traffic, and one port that listens for=0A= notifications.=0A= =0A= If the SSH Transport Model is configured to utilize AAA services,=0A= operators should consider configuring support for a local=0A= authentication mechanisms, such as local passwords, so SNMP can=0A= continue operating during times of network stress.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 30]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= The SSH protocol has its own windowing mechanism. RFC 4254 says: The=0A= window size specifies how many bytes the other party can send before=0A= it must wait for the window to be adjusted. Both parties use the=0A= following message to adjust the window. The SSH specifications leave=0A= it open when such window adjustment messages are created. Some=0A= implementations have been found to send window adjustment messages=0A= whenever received data has been passed to the application. Since=0A= window adjustment messages are padded, encrypted, hmac'ed, and=0A= wrapped, this results in noticeable bandwidth and processing=0A= overhead, which can be avoided by sending window adjustment messages=0A= less frequently.=0A= =0A= The SSH protocol requires the execution of CPU intensive calculations=0A= to establish a session key during session establishment. This means=0A= that short lived sessions become computationally expensive compared=0A= to USM, which does not have a notion of a session key. Other=0A= transport security protocols such as TLS support a session resumption=0A= feature that allows reusing a cached session key. Such a mechanism=0A= does not exist for SSH and thus SNMP applications should keep SSH=0A= sessions for longer time periods.=0A= =0A= To initiate SSH connections, an entity must be configured with SSH=0A= client credentials and information to authenticate the server. While=0A= hosts are often configured to be SSH clients, most internetworking=0A= devices are not. To send notifications over SSHTM, the=0A= internetworking device will need to be configured to be SSH clients.=0A= How this credential configuration is done is implementation and=0A= deployment specific. A scalable IETF standard protocol for=0A= configuration or key management is RECOMMENDED.=0A= =0A= 9. Security Considerations=0A= =0A= This document describes a transport model that permits SNMP to=0A= utilize SSH security services. The security threats and how the SSH=0A= Transport Model mitigates those threats is covered in detail=0A= throughout this memo.=0A= =0A= The SSH Transport Model relies on SSH mutual authentication, binding=0A= of keys, confidentiality and integrity. Any authentication method=0A= that meets the requirements of the SSH architecture will provide the=0A= properties of mutual authentication and binding of keys. While SSH=0A= does support turning off confidentiality and integrity, they SHOULD=0A= NOT be turned off when used with the SSH Transport Model.=0A= =0A= SSHv2 provides Perfect Forward Security (PFS) for encryption keys.=0A= PFS is a major design goal of SSH, and any well-designed keyex=0A= algorithm will provide it.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 31]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= The security implications of using SSH are covered in [RFC4251].=0A= =0A= The SSH Transport Model has no way to verify that server=0A= authentication was performed, to learn the host's public key in=0A= advance, or verify that the correct key is being used. The SSH=0A= Transport Model simply trusts that these are properly configured by=0A= the implementer and deployer.=0A= =0A= 9.1. noAuthPriv=0A= =0A= SSH provides the "none" userauth method, which is normally rejected=0A= by servers and used only to find out what userauth methods are=0A= supported. However, it is legal for a server to accept this method,=0A= which has the effect of not authenticating the SSH client to the SSH=0A= server. Doing this does not compromise authentication of the SSH=0A= server to the SSH client, nor does it compromise data confidentiality=0A= or data integrity.=0A= =0A= SSH supports anonymous access. If the SSH Transport Model can=0A= extract from SSH an authenticated principal to map to securityName,=0A= then anonymous access SHOULD be supported. It is possible for SSH to=0A= skip entity authentication of the client through the "none"=0A= authentication method to support anonymous clients, however in this=0A= case an implementation MUST still support data integrity within the=0A= SSH transport protocol and provide an authenticated principal for=0A= mapping to securityName for access control purposes.=0A= =0A= The RFC 3411 architecture does not permit noAuthPriv. The SSH=0A= Transport Model SHOULD NOT be used with an SSH connection with the=0A= "none" userauth method.=0A= =0A= 9.2. Use with SNMPv1/v2c Messages=0A= =0A= The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP=0A= 74) [RFC3584] always selects the SNMPv1(1) Security Model for an=0A= SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c=0A= message. When running SNMPv1/SNMPv2c over a secure transport like=0A= the SSH Transport Model, the securityName and securityLevel used for=0A= access control decisions are then derived from the community string,=0A= not the authenticated identity and securityLevel provided by the SSH=0A= Transport Model.=0A= =0A= 9.3. Skipping Public Key Verification=0A= =0A= Most key exchange algorithms are able to authenticate the SSH=0A= server's identity to the client. However, for the common case of DH=0A= signed by public keys, this requires the client to know the host's=0A= public key a priori and to verify that the correct key is being used.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 32]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= If this step is skipped, then authentication of the SSH server to the=0A= SSH client is not done. Data confidentiality and data integrity=0A= protection to the server still exist, but these are of dubious value=0A= when an attacker can insert himself between the client and the real=0A= SSH server. Note that some userauth methods may defend against this=0A= situation, but many of the common ones (including password and=0A= keyboard-interactive) do not, and in fact depend on the fact that the=0A= server's identity has been verified (so passwords are not disclosed=0A= to an attacker).=0A= =0A= SSH MUST NOT be configured to skip public key verification for use=0A= with the SSH Transport Model.=0A= =0A= 9.4. The 'none' MAC Algorithm=0A= =0A= SSH provides the "none" MAC algorithm, which would allow you to turn=0A= off data integrity while maintaining confidentiality. However, if=0A= you do this, then an attacker may be able to modify the data in=0A= flight, which means you effectively have no authentication.=0A= =0A= SSH MUST NOT be configured using the "none" MAC algorithm for use=0A= with the SSH Transport Model.=0A= =0A= 9.5. MIB Module Security=0A= =0A= There are no management objects defined in this MIB module that have=0A= a MAX-ACCESS clause of read-write and/or read-create. So, if this=0A= MIB module is implemented correctly, then there is no risk that an=0A= intruder can alter or create any management objects of this MIB=0A= module via direct SNMP SET operations.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The readable objects in this MIB module are not sensitive.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPSec or=0A= SSH), even then, there is no control as to who on the secure network=0A= is allowed to access and GET/SET (read/change/create/delete) the=0A= objects in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 33]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= provided by the SNMPv3 framework (see [RFC3410] section 8), including=0A= full support for the USM and the SSH Transport Model cryptographic=0A= mechanisms (for authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= 10. IANA Considerations=0A= =0A= IANA is requested to assign:=0A= =0A= 1. a TCP port number in the range 1..1023 in the=0A= http://www.iana.org/assignments/port-numbers registry which will=0A= be the default port for SNMP over an SSH Transport Model as=0A= defined in this document,=0A= =0A= 2. an SMI number under mib-2, for the MIB module in this document,=0A= =0A= 3. an SMI number under snmpDomains, for the snmpSSHDomain,=0A= =0A= 4. "snmp" as an SSH Service Name in the=0A= http://www.iana.org/assignments/ssh-parameters registry.=0A= =0A= 11. Acknowledgements=0A= =0A= The editors would like to thank Jeffrey Hutzelman for sharing his SSH=0A= insights.=0A= =0A= 12. References=0A= =0A= 12.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to=0A= Indicate Requirement Levels", BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Structure of Management=0A= Information Version 2 (SMIv2)", STD 58,=0A= RFC 2578, April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Textual Conventions for=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 34]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= SMIv2", STD 58, RFC 2579, April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins, D., and J.=0A= Schoenwaelder, "Conformance Statements for=0A= SMIv2", STD 58, RFC 2580, April 1999.=0A= =0A= [RFC2865] Rigney, C., Willens, S., Rubens, A., and W.=0A= Simpson, "Remote Authentication Dial In User=0A= Service (RADIUS)", RFC 2865, June 2000.=0A= =0A= [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An=0A= Architecture for Describing Simple Network=0A= Management Protocol (SNMP) Management=0A= Frameworks", STD 62, RFC 3411, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple=0A= Network Management Protocol (SNMP)=0A= Applications", STD 62, RFC 3413, December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B. Wijnen, "User-based=0A= Security Model (USM) for version 3 of the=0A= Simple Network Management Protocol (SNMPv3)",=0A= STD 62, RFC 3414, December 2002.=0A= =0A= [RFC3418] Presuhn, R., "Management Information Base (MIB)=0A= for the Simple Network Management Protocol=0A= (SNMP)", STD 62, RFC 3418, December 2002.=0A= =0A= [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,=0A= "Internationalizing Domain Names in=0A= Applications (IDNA)", RFC 3490, March 2003.=0A= =0A= [RFC3584] Frye, R., Levi, D., Routhier, S., and B.=0A= Wijnen, "Coexistence between Version 1, Version=0A= 2, and Version 3 of the Internet-standard=0A= Network Management Framework", BCP 74,=0A= RFC 3584, August 2003.=0A= =0A= [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Protocol Architecture", RFC 4251,=0A= January 2006.=0A= =0A= [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Authentication Protocol", RFC 4252,=0A= January 2006.=0A= =0A= [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Transport Layer Protocol", RFC 4253,=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 35]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= January 2006.=0A= =0A= [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Connection Protocol", RFC 4254,=0A= January 2006.=0A= =0A= [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport=0A= Subsystem for the Simple Network Management=0A= Protocol (SNMP)", draft-ietf-isms-tmsm-12 (work=0A= in progress), February 2008.=0A= =0A= 12.2. Informative References=0A= =0A= [RFC1994] Simpson, W., "PPP Challenge Handshake=0A= Authentication Protocol (CHAP)", RFC 1994,=0A= August 1996.=0A= =0A= [RFC3410] Case, J., Mundy, R., Partain, D., and B.=0A= Stewart, "Introduction and Applicability=0A= Statements for Internet-Standard Management=0A= Framework", RFC 3410, December 2002.=0A= =0A= [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn,=0A= G., and J. Arkko, "Diameter Base Protocol",=0A= RFC 3588, September 2003.=0A= =0A= [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,=0A= "Uniform Resource Identifier (URI): Generic=0A= Syntax", STD 66, RFC 3986, January 2005.=0A= =0A= [RFC4256] Cusack, F. and M. Forssen, "Generic Message=0A= Exchange Authentication for the Secure Shell=0A= Protocol (SSH)", RFC 4256, January 2006.=0A= =0A= [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and=0A= V. Welch, "Generic Security Service Application=0A= Program Interface (GSS-API) Authentication and=0A= Key Exchange for the Secure Shell (SSH)=0A= Protocol", RFC 4462, May 2006.=0A= =0A= [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D.,=0A= Williams, D., and W. Beck, "RADIUS Extension=0A= for Digest Authentication", RFC 5090,=0A= February 2008.=0A= =0A= [RFC4742] Wasserman, M. and T. Goddard, "Using the=0A= NETCONF Configuration Protocol over Secure=0A= SHell (SSH)", RFC 4742, December 2006.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 36]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Appendix A. Open Issues=0A= =0A= We need to reach consensus on some issues.=0A= =0A= Here is the current list of issues from the SSH Transport Model=0A= document where we need to reach consensus.=0A= =0A= o Issue #2: In USM, there is a mapping table that permits one user=0A= to have multiple methods for authentication, that map to a common=0A= securityName. Since SSH supports multiple authentication=0A= mechanisms, do we need to specify how these mechanism-specific=0A= identities map to a common securityName? This is important to=0A= permit admins to configure the TARGET-MIB, for example, with one=0A= common identity rather than mechanism-specific identities.=0A= =0A= o Issue #3: Mapping from the sshtmLCDTable identity to an SSH=0A= mechanisms-specific identity. This may just be the opposite=0A= transform of Issue #2.=0A= =0A= o Issue #5: what are the elements of procedure if you run for=0A= example SNMPv3/USM over SSHTM? The ASIs do not have parameters to=0A= identify two methods of authentication, and it is unclear how an=0A= outgoing message request would specify both SNMPv3/USM and SSHTM=0A= should be used, and which securityName/Level should be used for=0A= each.=0A= =0A= o Issue #6: We have not resolved whether the principal associated=0A= with a notification receiver must be a principal (aka user) or=0A= whether a hostname is adequate. In SNMPv3, the access controls=0A= are symmetrical - it is a user-level principal that access=0A= controls apply to, whether for R/R or notify applications. Is it=0A= acceptable to have user-level for R/R and host-level for notify=0A= functionality? A user that is not allowed to GET an object might=0A= be able to have the value of the object reported in a=0A= notification, or vice-versa. This is not much different that a=0A= principal having two different identities, one for R/R and another=0A= for notifications, or an admin configuring systems to send=0A= notifications to a different principal than those who do R/R=0A= processing. The WG needs to discuss this and reach some consensus=0A= on whether this is an issue or not, and how we want to proceed.=0A= =0A= o Issue #8: Should we allow transport models to select the=0A= corresponding security model by providing an additional parameter=0A= - the securityModel parameter - to tmStateReference, which would=0A= override the securityModel parameter extracted from a message=0A= header? Doing this would resolve Issue #5, and would allow the=0A= transport security model to be used with all SNMP message=0A= versions.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 37]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= TODO:=0A= =0A= finalize error processing in EOP=0A= =0A= Appendix B. Change Log=0A= =0A= From -10- to -11=0A= =0A= Changed LCD to sshtmLCDTable so it would not be confused with the=0A= snmpTsmLCD.=0A= =0A= Added operational considerations about SSH client credential=0A= distribution.=0A= =0A= =0A= =0A= From -09- to -10=0A= =0A= Issue #1: Made release of cached session info an implementation=0A= requirement on session close.=0A= =0A= Issue #4: UTF-8 syntax of userauth user name matches syntax of=0A= SnmpAdminString.=0A= =0A= Issue #7: Resolved to not describe how an SSH session is closed.=0A= =0A= From -08- to -09=0A= =0A= Updated MIB assignment to by rfc4181 compatible=0A= =0A= update MIB security considerations with coexistence issues=0A= =0A= update sameSession and tmSessionID support=0A= =0A= Fixed note about terminology, for consistency with SNMPv3.=0A= =0A= =0A= =0A= From -07- to -08=0A= =0A= Updated MIB=0A= =0A= update MIB security considerations=0A= =0A= develop sameSession and tmSessionID support=0A= =0A= Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 38]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Removed reference to mappings other than the identity function.=0A= =0A= From -06- to -07=0A= =0A= removed section on SSH to EngineID mappings, since engineIDs are=0A= not exposed to the transport model=0A= =0A= removed references to engineIDs and discovery=0A= =0A= removed references to securityModel.=0A= =0A= added security considerations warning about using with SNMPv1/v2c=0A= messages.=0A= =0A= added keyboard interactive discussion=0A= =0A= noted some implementation-dependent points=0A= =0A= removed references to transportModel; we use the transport domain=0A= as a model identifier.=0A= =0A= cleaned up ASIs=0A= =0A= modified MIB to be under snmpModules=0A= =0A= changed transportAddressSSH to snmpSSHDomain style addressing=0A= =0A= From -05- to -06=0A= =0A= replaced transportDomainSSH with RFC3417-style snmpSSHDomain=0A= =0A= replaced transportAddressSSH with RFC3417-style snmpSSHAddress=0A= =0A= Changed recvMessage to receiveMessage, and modified OUT to IN to=0A= match TMSM.=0A= =0A= From -04- to -05=0A= =0A= added sshtmUserTable=0A= =0A= moved session tabel into the transport model MIB from the=0A= transport subsystem MIB=0A= =0A= added and then removed Appendix A - Notification Tables=0A= Configuration (see Transport Security Model)=0A= =0A= made this document a specification of a transport model, rather=0A= than a security model in two parts. Eliminated TMSP and MPSP and=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 39]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= replaced them with "transport model" and "security model".=0A= =0A= Removed security-model-specific processing from this document.=0A= =0A= Removed discussion of snmpv3/v1/v2c message format co-existence=0A= =0A= changed tmSessionReference back to tmStateReference=0A= =0A= "From -03- to -04-"=0A= =0A= changed tmStateReference to tmSessionReference=0A= =0A= =0A= =0A= "From -02- to -03-"=0A= =0A= rewrote almost all sections=0A= =0A= merged ASI section and Elements of Procedure sections=0A= =0A= removed references to the SSH user, in preference to SSH client=0A= =0A= updated references=0A= =0A= creayted a conventions section to identify common terminology.=0A= =0A= rewrote sections on how SSH addresses threats=0A= =0A= rewrote mapping SSH to engineID=0A= =0A= eliminated discovery section=0A= =0A= detailed the Elements of Procedure=0A= =0A= eliminated secrtions on msgFlags, transport parameters=0A= =0A= resolved issues of opening notifications=0A= =0A= eliminated sessionID (TMSM needs to be updated to match)=0A= =0A= eliminated use of tmsSessiontable except as an example=0A= =0A= updated Security Considerations=0A= =0A= "From -01- to -02-"=0A= =0A= Added TransportDomainSSH and Address=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 40]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Removed implementation considerations=0A= =0A= Changed all "user auth" to "client auth"=0A= =0A= Removed unnecessary MIB module objects=0A= =0A= updated references=0A= =0A= improved consistency of references to TMSM as architectural=0A= extension=0A= =0A= updated conventions=0A= =0A= updated threats to be more consistent with RFC3552=0A= =0A= discussion of specific SSH mechanism configurations moved to=0A= security considerations=0A= =0A= modified session discussions to reference TMSM sessions=0A= =0A= expanded discussion of engineIDs=0A= =0A= wrote text to clarify the roles of MPSP and TMSP=0A= =0A= clarified how snmpv3 message parts are ised by SSHSM=0A= =0A= modified nesting of subsections as needed=0A= =0A= securityLevel used by the SSH Transport Model always equals=0A= authpriv=0A= =0A= removed discussion of using SSHSM with SNMPv1/v2c=0A= =0A= started updating Elements of Procedure, but realized missing info=0A= needs discussion.=0A= =0A= updated MIB module relationship to other MIB modules=0A= =0A= "From -00- to -01-"=0A= =0A= -00- initial draft as ISMS work product:=0A= =0A= updated references to SecSH RFCs=0A= =0A= Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19,=0A= 20, 29, 30, and 32.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 41]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= updated security considerations=0A= =0A= removed Juergen Schoenwaelder from authors, at his request=0A= =0A= ran the mib module through smilint=0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= =0A= EMail: jsalowey@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 42]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2008).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 2, 2009 [Page 43]=0A= =0C=0A= =0A= ------=_NextPart_000_0021_01C8DC53.85533C00 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_0021_01C8DC53.85533C00-- From isms-bounces@ietf.org Wed Jul 9 12:09:17 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635DB3A6B4A; Wed, 9 Jul 2008 12:09:17 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E1E3A6C45 for ; Wed, 2 Jul 2008 03:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=-1.890, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MANGLED_TOOL=2.3, MIME_QP_LONG_LINE=1.396] 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 F7Yp38W1MQKG for ; Wed, 2 Jul 2008 03:04:15 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id F111B3A6C21 for ; Wed, 2 Jul 2008 03:04:14 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id kxwL1Z00716AWCUA401A00; Wed, 02 Jul 2008 10:04:24 +0000 Received: from Harrington73653 ([222.128.247.81]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id ky4A1Z0021m6Z1J8Sy4DhR; Wed, 02 Jul 2008 10:04:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=cSulFOGnMtTIDTCgaNEA:9 a=DztmDG0K68-E9tuJNrZPfEnrUwgA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 a=48vgC7mUAAAA:8 a=I0CVDw5ZAAAA:8 a=YxIpXM9k_p3wYmU1WDgA:9 a=5BW6yP6dW4BTqcMXqqIA:7 a=IFDWQRt_Q3Z9gSHTE1HNUQgdK2UA:4 a=FvgKqOQ44qUA:10 a=oBKaSYGbyHAA:10 a=AVCpO1ehElwA:10 a=kLdjEiV55KYA:10 a=3BuQvuyjSHIA:10 a=3j06tXsvO8IA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=c5zHXd76wwQA:10 From: "David Harrington" To: Date: Wed, 2 Jul 2008 18:04:09 +0800 Message-ID: <005401c8dc2a$fe053370$51f780de@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0055_01C8DC6E.0C287370" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjcKvh/+otPSRv7QkibhxvWpl84Aw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailman-Approved-At: Wed, 09 Jul 2008 12:09:16 -0700 Subject: [Isms] pre11 update X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C8DC6E.0C287370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, While you guys were blissfully sleeping your night away, I spent my afternoon updating the document. Here's an update. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0055_01C8DC6E.0C287370 Content-Type: text/plain; name="draft-ietf-isms-secshell-pre11a.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-secshell-pre11a.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Standards Track J. Salowey=0A= Expires: January 3, 2009 Cisco Systems=0A= July 2, 2008=0A= =0A= =0A= Secure Shell Transport Model for SNMP=0A= draft-ietf-isms-secshell-11=0A= =0A= Status of This Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on January 3, 2009.=0A= =0A= Abstract=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 1]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 3=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 6=0A= 3. How SSHTM Fits into the Transport Subsystem . . . . . . . . . 7=0A= 3.1. Security Capabilities of this Model . . . . . . . . . . . 8=0A= 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 3.1.2. Message Authentication . . . . . . . . . . . . . . . . 9=0A= 3.1.3. Authentication Protocol Support . . . . . . . . . . . 10=0A= 3.1.4. Privacy Protocol Support . . . . . . . . . . . . . . . 10=0A= 3.1.5. Protection against Message Replay, Delay and=0A= Redirection . . . . . . . . . . . . . . . . . . . . . 10=0A= 3.1.6. SSH Subsystem . . . . . . . . . . . . . . . . . . . . 11=0A= 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 11=0A= 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 12=0A= 4. Passing Security Parameters . . . . . . . . . . . . . . . . . 12=0A= 4.1. tmStateReference . . . . . . . . . . . . . . . . . . . . . 12=0A= 4.2. tmSecurityName . . . . . . . . . . . . . . . . . . . . . . 13=0A= 4.3. tmSameSecurity . . . . . . . . . . . . . . . . . . . . . . 14=0A= 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 15=0A= 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 15=0A= 5.2. Procedures for an Outgoing Message . . . . . . . . . . . . 16=0A= 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 17=0A= 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 19=0A= 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 20=0A= 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 20=0A= 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 20=0A= 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 20=0A= 6.3.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 20=0A= 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 21=0A= 8. Operational Considerations . . . . . . . . . . . . . . . . . . 30=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31=0A= 9.1. noAuthPriv . . . . . . . . . . . . . . . . . . . . . . . . 31=0A= 9.2. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 32=0A= 9.3. Skipping Public Key Verification . . . . . . . . . . . . . 32=0A= 9.4. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 32=0A= 9.5. MIB Module Security . . . . . . . . . . . . . . . . . . . 33=0A= 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33=0A= 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34=0A= 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34=0A= 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34=0A= 12.2. Informative References . . . . . . . . . . . . . . . . . . 35=0A= Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 36=0A= Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 37=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 2]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH) [RFC4251]=0A= within a transport subsystem [I-D.ietf-isms-tmsm]. The transport=0A= model specified in this memo is referred to as the Secure Shell=0A= Transport Model (SSHTM).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= It is important to understand the SNMP architecture [RFC3411] and the=0A= terminology of the architecture to understand where the Transport=0A= Model described in this memo fits into the architecture and interacts=0A= with other subsystems within the architecture.=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications. This is=0A= consistent with the IESG decision to not require the SNMPv3=0A= terminology be modified to match the usage of other non-SNMP=0A= specifications when SNMPv3 was advanced to Full Standard.=0A= =0A= Authentication in this document typically refers to the English=0A= meaning of "serving to prove the authenticity of" the message, not=0A= data source authentication or peer identity authentication.=0A= =0A= The terms "manager" and "agent" are not used in this document,=0A= because in the RFC 3411 architecture [RFC3411], all SNMP entities=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 3]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= have the capability of acting in either manager or agent or in both=0A= roles depending on the SNMP application types supported in the=0A= implementation. Where distinction is required, the application names=0A= of Command Generator, Command Responder, Notification Originator,=0A= Notification Receiver, and Proxy Forwarder are used. See "SNMP=0A= Applications" [RFC3413] for further information.=0A= =0A= Throughout this document, the terms "client" and "server" are used to=0A= refer to the two ends of the SSH transport connection. The client=0A= actively opens the SSH connection, and the server passively listens=0A= for the incoming SSH connection. Either SNMP entity may act as=0A= client or as server, as discussed further below.=0A= =0A= The User-Based Security Model (USM) [RFC3414] is a mandatory-to-=0A= implement Security Model in STD 62. While SSH and USM frequently=0A= refer to a user, the terminology preferred in RFC3411 [RFC3411] and=0A= in this memo is "principal". A principal is the "who" on whose=0A= behalf services are provided or processing takes place. A principal=0A= can be, among other things, an individual acting in a particular=0A= role; a set of individuals, with each acting in a particular role; an=0A= application or a set of applications, or a combination of these=0A= within an administrative domain.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= Sections requiring further editing are identified by [todo] markers=0A= in the text. Points requiring further WG research and discussion are=0A= identified by [discuss] markers in the text.=0A= =0A= Note to RFC Editor - if the previous paragraph and this note have not=0A= been removed, please send the document back to the editor to remove=0A= this.=0A= =0A= 1.3. Modularity=0A= =0A= The reader is expected to have read and understood the description of=0A= the SNMP architecture, as defined in [RFC3411], and the Transport=0A= Subsystem architecture extension specified in "Transport Subsystem=0A= for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm].=0A= =0A= This memo describes the Secure Shell Transport Model for SNMP, a=0A= specific SNMP transport model to be used within the SNMP transport=0A= subsystem to provide authentication, encryption, and integrity=0A= checking of SNMP messages.=0A= =0A= In keeping with the RFC 3411 design decision to use self-contained=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 4]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= documents, this document defines the elements of procedure and=0A= associated MIB module objects which are needed for processing the=0A= Secure Shell Transport Model for SNMP.=0A= =0A= This modularity of specification is not meant to be interpreted as=0A= imposing any specific requirements on implementation.=0A= =0A= 1.4. Motivation=0A= =0A= Version 3 of the Simple Network Management Protocol (SNMPv3) added=0A= security to the protocol. The User-based Security Model (USM)=0A= [RFC3414] was designed to be independent of other existing security=0A= infrastructures, to ensure it could function when third party=0A= authentication services were not available, such as in a broken=0A= network. As a result, USM utilizes a separate user and key=0A= management infrastructure. Operators have reported that deploying=0A= another user and key management infrastructure in order to use SNMPv3=0A= is a reason for not deploying SNMPv3.=0A= =0A= This memo describes a transport model that will make use of the=0A= existing and commonly deployed Secure Shell security infrastructure.=0A= This transport model is designed to meet the security and operational=0A= needs of network administrators, maximize usability in operational=0A= environments to achieve high deployment success and at the same time=0A= minimize implementation and deployment costs to minimize deployment=0A= time.=0A= =0A= This document addresses the requirement for the SSH client to=0A= authenticate the SSH server, for the SSH server to authenticate the=0A= SSH client, and describes how SNMP can make use of the authenticated=0A= identities in authorization policies for data access, in a manner=0A= that is independent of any specific access control model.=0A= =0A= This document addresses the requirement to utilize client=0A= authentication and key exchange methods which support different=0A= security infrastructures and provide different security properties.=0A= This document describes how to use client authentication as described=0A= in "SSH Authentication Protocol" [RFC4252]. The SSH Transport Model=0A= should work with any of the ssh-userauth methods including the=0A= "publickey", "password", "hostbased", "none", "keyboard-interactive",=0A= "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx"=0A= (see http://www.iana.org/assignments/ssh-parameters). The use of the=0A= "none" authentication method is NOT RECOMMENDED, as described in=0A= Security Considerations. Local accounts may be supported through the=0A= use of the publickey, hostbased or password methods. The password=0A= method allows for integration with deployed password infrastructure=0A= such as AAA servers using the RADIUS protocol [RFC2865]. The SSH=0A= Transport Model SHOULD be able to take advantage of future defined=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 5]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= ssh-userauth methods, such as those that might make use of X.509=0A= certificate credentials.=0A= =0A= It is desirable to use mechanisms that could unify the approach for=0A= administrative security for SNMPv3 and Command Line interfaces (CLI)=0A= and other management interfaces. The use of security services=0A= provided by Secure Shell is the approach commonly used for the CLI,=0A= and is the approach being adopted for use with NETCONF [RFC4742].=0A= This memo describes a method for invoking and running the SNMP=0A= protocol within a Secure Shell (SSH) session as an SSH subsystem.=0A= =0A= This memo describes how SNMP can be used within a Secure Shell (SSH)=0A= session, using the SSH connection protocol [RFC4254] over the SSH=0A= transport protocol, using SSH user-auth [RFC4252] for authentication.=0A= =0A= There are a number of challenges to be addressed to map Secure Shell=0A= authentication method parameters into the SNMP architecture so that=0A= SNMP continues to work without any surprises. These are discussed in=0A= detail below.=0A= =0A= 1.5. Constraints=0A= =0A= The design of this SNMP Transport Model is influenced by the=0A= following constraints:=0A= =0A= 1. In times of network stress, the transport protocol and its=0A= underlying security mechanisms SHOULD NOT depend upon the ready=0A= availability of other network services (e.g., Network Time=0A= Protocol (NTP) or AAA protocols).=0A= =0A= 2. When the network is not under stress, the transport model and its=0A= underlying security mechanisms MAY depend upon the ready=0A= availability of other network services.=0A= =0A= 3. It may not be possible for the transport model to determine when=0A= the network is under stress.=0A= =0A= 4. A transport model should require no changes to the SNMP=0A= architecture.=0A= =0A= 5. A transport model should require no changes to the underlying=0A= protocol.=0A= =0A= 2. The Secure Shell Protocol=0A= =0A= SSH is a protocol for secure remote login and other secure network=0A= services over an insecure network. It consists of three major=0A= protocol components, and add-on methods for user authentication:=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 6]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= o The Transport Layer Protocol [RFC4253] provides server=0A= authentication, and message confidentiality and integrity. It may=0A= optionally also provide compression. The transport layer will=0A= typically be run over a TCP/IP connection, but might also be used=0A= on top of any other reliable data stream.=0A= =0A= o The User Authentication Protocol [RFC4252] authenticates the=0A= client-side principal to the server. It runs over the transport=0A= layer protocol.=0A= =0A= o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel=0A= into several logical channels. It runs over the transport after=0A= successfully authenticating the principal.=0A= =0A= o Generic Message Exchange Authentication [RFC4256] is a general=0A= purpose authentication method for the SSH protocol, suitable for=0A= interactive authentications where the authentication data should=0A= be entered via a keyboard=0A= =0A= o Generic Security Service Application Program Interface (GSS-API)=0A= Authentication and Key Exchange for the Secure Shell (SSH)=0A= Protocol [RFC4462] describes methods for using the GSS-API for=0A= authentication and key exchange in SSH. It defines an SSH user=0A= authentication method that uses a specified GSS-API mechanism to=0A= authenticate a user, and a family of SSH key exchange methods that=0A= use GSS-API to authenticate a Diffie-Hellman key exchange.=0A= =0A= The client sends a service request once a secure transport layer=0A= connection has been established. A second service request is sent=0A= after client authentication is complete. This allows new protocols=0A= to be defined and coexist with the protocols listed above.=0A= =0A= The connection protocol provides channels that can be used for a wide=0A= range of purposes. Standard methods are provided for setting up=0A= secure interactive shell sessions and for forwarding ("tunneling")=0A= arbitrary TCP/IP ports and X11 connections.=0A= =0A= 3. How SSHTM Fits into the Transport Subsystem=0A= =0A= A transport model plugs into the Transport Subsystem=0A= [I-D.ietf-isms-tmsm]. The SSH Transport Model thus fits between the=0A= underlying SSH transport layer and the message dispatcher [RFC3411].=0A= =0A= The SSH Transport Model will establish a channel between itself and=0A= the SSH Transport Model of another SNMP engine. The sending=0A= transport model passes unencrypted messages from the dispatcher to=0A= SSH to be encrypted, and the receiving transport model accepts=0A= decrypted incoming messages from SSH and passes them to the=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 7]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= dispatcher.=0A= =0A= After an SSH Transport model channel is established, then SNMP=0A= messages can conceptually be sent through the channel from one SNMP=0A= message dispatcher to another SNMP message dispatcher. Multiple SNMP=0A= messages MAY be passed through the same channel.=0A= =0A= The SSH Transport Model of an SNMP engine will perform the=0A= translation between SSH-specific security parameters and SNMP-=0A= specific, model-independent parameters.=0A= =0A= 3.1. Security Capabilities of this Model=0A= =0A= 3.1.1. Threats=0A= =0A= The Secure Shell Transport Model provides protection against the=0A= threats identified by the RFC 3411 architecture [RFC3411]:=0A= =0A= 1. Message stream modification - SSH provides for verification that=0A= each received message has not been modified during its=0A= transmission through the network.=0A= =0A= 2. Information modification - SSH provides for verification that the=0A= contents of each received message has not been modified during=0A= its transmission through the network, data has not been altered=0A= or destroyed in an unauthorized manner, nor have data sequences=0A= been altered to an extent greater than can occur non-maliciously.=0A= =0A= 3. Masquerade - SSH provides for both verification of the identity=0A= of the SSH server and verification of the identity of the SSH=0A= client. SSH provides verification of the identity of the SSH=0A= server through the SSH Transport Protocol server authentication=0A= [RFC4253].=0A= =0A= 4. Verification of principal identity is important for use with the=0A= SNMP access control subsystem, to ensure that only authorized=0A= principals have access to potentially sensitive data. The SSH=0A= user identity is provided to the transport model, so it can be=0A= used to map to an SNMP model-independent securityName for use=0A= with SNMP access control and notification configuration. (The=0A= identity may undergo various transforms before it maps to the=0A= securityName.)=0A= =0A= 5. Authenticating both the SSH server and the SSH client ensures the=0A= authenticity of the SNMP engine that provides MIB data.=0A= Operators or management applications might act upon the data they=0A= receive (e.g., raise an alarm for an operator, modify the=0A= configuration of the device that sent the notification, modify=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 8]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= the configuration of other devices in the network as the result=0A= of the notification, and so on), so it is important to know that=0A= the provider of MIB data is authentic.=0A= =0A= 6. Disclosure - the SSH Transport Model provides that the contents=0A= of each received SNMP message are protected from disclosure to=0A= unauthorized persons.=0A= =0A= 7. Replay - SSH ensures that cryptographic keys established at the=0A= beginning of the SSH session and stored in the SSH session state=0A= are fresh new session keys generated for each session. These are=0A= used to authenticate and encrypt data, and to prevent replay=0A= across sessions. SSH uses sequence information to prevent the=0A= replay and reordering of messages within a session.=0A= =0A= 3.1.2. Message Authentication=0A= =0A= The RFC 3411 architecture recognizes three levels of security:=0A= =0A= - without authentication and without privacy (noAuthNoPriv)=0A= =0A= - with authentication but without privacy (authNoPriv)=0A= =0A= - with authentication and with privacy (authPriv)=0A= =0A= The Secure Shell protocol provides support for encryption and data=0A= integrity. While it is technically possible to support no=0A= authentication and no encryption in SSH it is NOT RECOMMENDED by=0A= [RFC4253].=0A= =0A= The SSH Transport Model determines from SSH the identity of the=0A= authenticated principal, and the type and address associated with an=0A= incoming message, and the SSH Transport Model provides this=0A= information to SSH for an outgoing message. The transport layer=0A= algorithms used to provide authentication, data integrity and=0A= encryption SHOULD NOT be exposed to the SSH Transport Model layer.=0A= The SNMPv3 WG deliberately avoided this and settled for an assertion=0A= by the security model that the requirements of securityLevel were met=0A= The SSH Transport Model has no mechanisms by which it can test=0A= whether an underlying SSH connection provides auth or priv, so the=0A= SSH Transport Model trusts that the underlying SSH connection has=0A= been properly configured to support authPriv security=0A= characteristics.=0A= =0A= The SSH Transport Model does not know about the algorithms or options=0A= to open SSH sessions that match different securityLevels. For=0A= interoperability of the trust assumptions between SNMP engines, an=0A= SSH Transport Model-compliant implementation MUST use an SSH=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 9]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= connection that provides authentication, data integrity and=0A= encryption that meets the highest level of SNMP security (authPriv).=0A= Outgoing messages requested by SNMP applications and specified with a=0A= lesser securityLevel (noAuthNoPriv or authNoPriv) are sent by the SSH=0A= Transport Model as authPriv securityLevel.=0A= =0A= The security protocols used in the Secure Shell Authentication=0A= Protocol [RFC4252] and the Secure Shell Transport Layer Protocol=0A= [RFC4253] are considered acceptably secure at the time of writing.=0A= However, the procedures allow for new authentication and privacy=0A= methods to be specified at a future time if the need arises.=0A= =0A= 3.1.3. Authentication Protocol Support=0A= =0A= The SSH Transport Model should support any server or client=0A= authentication mechanism supported by SSH. This includes the three=0A= authentication methods described in the SSH Authentication Protocol=0A= document [RFC4252] - publickey, password, and host-based - and=0A= keyboard interactive and others.=0A= =0A= The password authentication mechanism allows for integration with=0A= deployed password based infrastructure. It is possible to hand a=0A= password to a service such as RADIUS [RFC2865] or Diameter [RFC3588]=0A= for validation. The validation could be done using the user-name and=0A= user-password attributes. It is also possible to use a different=0A= password validation protocol such as CHAP [RFC1994] or digest=0A= authentication [RFC5090] to integrate with RADIUS or Diameter. At=0A= some point in the processing, these mechanisms require the password=0A= be made available as clear text on the device that is authenticating=0A= the password which might introduce threats to the authentication=0A= infrastructure. [DISCUSS: do we really need this paragraph?=0A= =0A= GSSKeyex [RFC4462] provides a framework for the addition of client=0A= authentication mechanisms which support different security=0A= infrastructures and provide different security properties.=0A= Additional authentication mechanisms, such as one that supports X.509=0A= certificates, may be added to SSH in the future.=0A= =0A= 3.1.4. Privacy Protocol Support=0A= =0A= The SSH transport model supports any privacy protocol used with SSH.=0A= [DISCUSS: The authentication support section goes into significant=0A= detail; should the same be done here?]=0A= =0A= 3.1.5. Protection against Message Replay, Delay and Redirection=0A= =0A= SSH uses sequence numbers and integrity checks to protect against=0A= replay and reordering of messages within a connection.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 10]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= SSH also provides protection against replay of entire sessions. In a=0A= properly-implemented Diffie-Helman exchange, both sides will generate=0A= new random numbers for each exchange, which means the encryption and=0A= integrity keys will be distinct for every session.=0A= =0A= 3.1.6. SSH Subsystem=0A= =0A= This document describes the use of an SSH subsystem for SNMP to make=0A= SNMP usage distinct from other usages.=0A= =0A= SSH subsystems of type "snmp" are opened by the SSH Transport Model=0A= during the elements of procedure for an outgoing SNMP message. Since=0A= the sender of a message initiates the creation of an SSH session if=0A= needed, the SSH session will already exist for an incoming message or=0A= the incoming message would never reach the SSH Transport Model.=0A= [DISCUSS: If a notification originator opens a subsystem called=0A= "snmp" and a command generator opens a subsystem called "snmp", will=0A= that be confusing to SSH? ]=0A= =0A= Implementations MAY choose to instantiate SSH sessions in=0A= anticipation of outgoing messages. This approach might be useful to=0A= ensure that an SSH session to a given target can be established=0A= before it becomes important to send a message over the SSH session.=0A= Of course, there is no guarantee that a pre-established session will=0A= still be valid when needed.=0A= =0A= SSH sessions are uniquely identified within the SSH Transport Model=0A= by the combination of transportAddressType, transportAddress,=0A= securityName, and securityLevel associated with each session.=0A= =0A= 3.2. Security Parameter Passing=0A= =0A= For incoming messages, SSH-specific security parameters are=0A= translated by the transport model into security parameters=0A= independent of the transport and security models. The transport=0A= model accepts messages from the SSH subsystem, and records the=0A= transport-related and SSH-security-related information, including the=0A= authenticated identity, in a cache referenced by tmStateReference,=0A= and passes the WholeMsg and the tmStateReference to the dispatcher=0A= using the receiveMessage() ASI (Application Service Interface).=0A= =0A= For outgoing messages, the transport model takes input provided by=0A= the dispatcher in the sendMessage() ASI. The SSH Transport Model=0A= converts that information into suitable security parameters for SSH,=0A= establishes sessions as needed, and passes messages to the SSH=0A= subsystem for sending.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 11]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 3.3. Notifications and Proxy=0A= =0A= SSH connections may be initiated by command generators or by=0A= notification originators. Command generators are frequently operated=0A= by a human, but notification originators are usually unmanned=0A= automated processes. As a result, it may be necessary to provision=0A= authentication credentials on the SNMP engine containing the=0A= notification originator, or use a third party key provider such as=0A= Kerberos, so the engine can successfully authenticate to an engine=0A= containing a notification receiver.=0A= =0A= The targets to whom notifications should be sent is typically=0A= determined and configured by a network administrator. The SNMP-=0A= TARGET-MIB module [RFC3413] contains objects for defining management=0A= targets, including transport domains and addresses and security=0A= parameters, for applications such as notifications and proxy.=0A= =0A= For the SSH Transport Model, transport type and address are=0A= configured in the snmpTargetAddrTable, and the securityName, and=0A= securityLevel parameters are configured in the snmpTargetParamsTable.=0A= The default approach is for an administrator to statically=0A= preconfigure this information to identify the targets authorized to=0A= receive notifications or perform proxy.=0A= =0A= These MIB modules may be configured using SNMP or other=0A= implementation-dependent mechanisms, such as CLI scripting or loading=0A= a configuration file. It may be necessary to provide additional=0A= implementation-specific configuration of SSH parameters.=0A= =0A= 4. Passing Security Parameters=0A= =0A= For the SSH Transport Model, some state needs to be maintained using=0A= tmStateReference. RFC3411 discusses a securityStateReference, which=0A= is not accessible to the Transport Subsystem.=0A= =0A= 4.1. tmStateReference=0A= =0A= Upon opening each SSH connection, the SSH Transport Model stores=0A= model- and mechanism-specific information about the connection in a=0A= cache, referenced by tmStateReference. This connection information=0A= might be consistent across multiple messages, and might also be=0A= stored in the sshtmLCDTable.=0A= =0A= For interoperability with Security Model designs, the state=0A= referenced by tmStateReference MUST include the following fields=0A= (with sample values). See the Elements of Procedure for detailed=0A= processing instructions on the use of these fields by the SSH=0A= Transport Model.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 12]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= tmTransport =3D snmpSSHDomain=0A= =0A= tmAddress =3D an snmpSSHAddress=0A= =0A= tmRequestedSecurityLevel =3D ["noAuthNoPriv" | "authNoPriv" |=0A= "authPriv" ]=0A= =0A= tmTransportSecurityLevel =3D "authPriv"=0A= =0A= tmSecurityName =3D the principal name [to be] authenticated by SSH.=0A= See the section on tmSecurityName below.=0A= =0A= tmSameSecurity =3D true or false, depending on whether the Security=0A= Model requires that an outgoing response be sent using the same=0A= security parameters as were used for the incoming request or for=0A= any other security-model-dependent reason. See the section on=0A= tmSameSecurity below.=0A= =0A= =0A= =0A= The state referenced by tmStateReference for an SSH Transport Model=0A= should also contain an implementation-dependent identifier (e.g.,=0A= tmSessionID).=0A= =0A= The per-session state that is referenced by tmStateReference may be=0A= saved across multiple messages in a Local Configuration Datastore=0A= (sshtmLCDTable).=0A= =0A= The tmStateReference cache should be generated anew for each message,=0A= so that it can be used to determine whether the SSH session available=0A= for sending an outgoing message is the same SSH session as was used=0A= when receiving the corresponding incoming message (e.g., a response=0A= to a request), when tmSameSecurity is set.=0A= =0A= A Transport Model will maintain any mapping between transport-=0A= specific security parameters and tmTransportSecurityLevel and=0A= tmSecurityName, and will verify for outgoing messages that the=0A= transport-provided security is at least as strong as=0A= tmRequestedSecurityLevel..=0A= =0A= The SSH Transport Model implementation has the responsibility for=0A= "garbage collection" - releasing any associated tmStateReference when=0A= a session is closed.=0A= =0A= 4.2. tmSecurityName=0A= =0A= How the SSH identity is extracted from the SSH layer is=0A= implementation-dependent.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 13]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= tmSecurityName is a human-readable name in SnmpAdminString format=0A= that is mapped from the identity that has been successfully=0A= authenticated by SSH. By default, tmSecurityName is determined from=0A= the value of the user name field of the SSH_MSG_USERAUTH_REQUEST=0A= message for which a SSH_MSG_USERAUTH_SUCCESS has been received.=0A= =0A= As described in RFC4252 section 5, all authentication requests,=0A= regardless of authentication mechanism, MUST use the same message=0A= format, which includes a byte to indicate SSH_MSG_USERAUTH_REQUEST,=0A= and a user name field. How the authenticated user name is made=0A= available to the SNMP implementation is SSH-implementation dependent.=0A= =0A= The SSH protocol is not always clear on whether the user name field=0A= must be filled in, so for some implementations, it may be necessary=0A= to use a non-default mapping algorithm. How the SSH identity is=0A= mapped to a tmSecurityName should be administratively configurable.=0A= The sshtmLCDTransformPolicy object is used during the elements of=0A= procedure to determine whether the default transform or an=0A= alternative tranbsform is used.=0A= =0A= The tmSecurityName may ultimately be used to identify the layer 8=0A= principal for use in such things as logging and for access control=0A= policy assignment. For example, USM provides this by pre-=0A= configuration of the mapping of the auth protocol and auth-specific=0A= credentials to a securityName, in the usmUserTable. Transport model=0A= transforms SHOULD generate a predictable tmSecurityName representing=0A= the principal.=0A= =0A= 4.3. tmSameSecurity=0A= =0A= If a Secure Shell transport session is closed between the time a=0A= request message is received and the corresponding response message is=0A= sent, then the response message MUST be discarded, even if a new SSH=0A= session has been established. The SSH Transport Model does not know=0A= whether a message contains a request or response (at least=0A= architecturally, this is not available to the transport model;=0A= implementations may choose to make this available for simplicity.)=0A= =0A= Each Security Model that supports the tmStateReference cache will=0A= pass a tmSameSecurity parameter in the tmStateReference cache for=0A= outgoing messages to indicate whether the same security MUST be used=0A= for the outgoing message as was used for the corresponding incoming=0A= message (e.g., a request-response pair). The tmStateReference for=0A= the Secure Shell Transport Model SHOULD also include a tmSessionID to=0A= indicate which SSH session should be used for the corresponding=0A= response.=0A= =0A= If the tmSameSecurity is indicated, but the session identified in the=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 14]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= tmStateReference does not match the current established SSH session=0A= for the tmTransportDomain, tmTransportAddress, tmSecurityName, and=0A= tmSecurityLevel, then the message MUST be discarded, and the=0A= dispatcher should be notified that the sending of the message failed.=0A= =0A= 5. Elements of Procedure=0A= =0A= Abstract service interfaces have been defined by RFC 3411 to describe=0A= the conceptual data flows between the various subsystems within an=0A= SNMP entity. The Secure Shell Transport Model uses some of these=0A= conceptual data flows when communicating between subsystems. These=0A= RFC 3411-defined data flows are referred to here as public=0A= interfaces.=0A= =0A= To simplify the elements of procedure, the release of state=0A= information is not always explicitly specified. As a general rule,=0A= if state information is available when a message gets discarded, the=0A= message-state information should also be released, and if state=0A= information is available when a session is closed, the session state=0A= information should also be released.=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected. ContextEngineID and contextName are not accessible to=0A= Transport Models, so contextEngineID is set to the local value of=0A= snmpEngineID, and contextName is set to the default context for error=0A= counters.=0A= =0A= 5.1. Procedures for an Incoming Message=0A= =0A= 1) The SSH Transport Model queries the SSH engine, in an=0A= implementation-dependent manner, to determine the transportAddress,=0A= the principal name authenticated by SSH, and a session identifier.=0A= =0A= By default, the principal name is the value of the user name field of=0A= the SSH_MSG_USERAUTH_REQUEST message for which a=0A= SSH_MSG_USERAUTH_SUCCESS has been received. How this name is=0A= extracted from the SSH environment is implementation-dependent.=0A= =0A= 2) Using the sshtmLCDTransformPolicy, calculate a corresponding=0A= tmSecurityName value. Determine if there is a row in the=0A= sshtmLCDTable with the transport address and an sshtmLCDSecurityName=0A= that matches the calculated tmSecurityName value.=0A= =0A= 3) If one does not exist, create an entry in the sshtmLCDTable:=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 15]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= sshtmTransportAddress =3D transport address=0A= =0A= sshtmLCDSecurityName =3D calculated tmSecurityName=0A= =0A= sshtmLCDPrincipal=3Dthe SSH principal=0A= =0A= sshtmLCDSessionID=3Dthe SSH session identifier=0A= =0A= sshtmStorageType=3Dvolatile=0A= =0A= sshtmRowStatus=3DcreateAndGo=0A= =0A= 4) Create a tmStateReference cache for subsequent reference to the=0A= information.=0A= =0A= tmTransportDomain =3D snmpSSHDomain=0A= =0A= tmTransportAddress =3D sshtmLCDTransportAddress=0A= =0A= tmSecurityLevel =3D "authPriv"=0A= =0A= tmSecurityName =3D sshtmLCDSecurityName=0A= =0A= tmSessionID =3D an implementation-dependent value that can be used=0A= to detect when a session has closed and been replaced by another=0A= session. The value in tmStateReference should identify the=0A= session over which the message was received.=0A= =0A= Then the Transport model passes the message to the Dispatcher using=0A= the following ASI:=0A= =0A= statusInformation =3D=0A= receiveMessage(=0A= IN transportDomain -- snmpSSHDomain=0A= IN transportAddress -- address for the received message=0A= IN wholeMessage -- the whole SNMP message from SSH=0A= IN wholeMessageLength -- the length of the SNMP message=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= 5.2. Procedures for an Outgoing Message=0A= =0A= The Dispatcher passes the information to the Transport Model using=0A= the ASI defined in the transport subsystem:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 16]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= statusInformation =3D=0A= sendMessage(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN outgoingMessage -- the message to send=0A= IN outgoingMessageLength -- its length=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= The SSH Transport Model performs the following tasks:=0A= =0A= 1) Extract the tmTransportAddress, tmSecurityName, tmSameSecurity,=0A= and tmSessionID from the tmStateReference. (SSHTM ignores the=0A= provided tmTransportDomain and tmRequestedSecurityLevel.)=0A= =0A= 2) Using tmTransportAddress and tmSecurityName, determine if a=0A= corresponding row exists in the sshtmLCDTable.=0A= =0A= 3) If there is a corresponding row, and tmSameSecurity is true,=0A= and tmSessionID does not match sshtmLCDSessionID, then increment=0A= the sshtmSessionNoAvailableSessions counter, discard the message=0A= and return the error indication in the statusInformation.=0A= Processing of this message stops.=0A= =0A= 4) If there is no corresponding row, then call openSession() with=0A= the tmTransportAddress and tmSecurityName as parameters.=0A= =0A= 4b) If an error is returned from OpenSession(), then discard the=0A= message, and return the error indication returned by OpenSession()=0A= in the statusInformation.=0A= =0A= 5) Determine any SSH-implementation-specific parameters from the=0A= sshtmLCDTable=0A= =0A= 6) Pass the wholeMessage to SSH for encapsulation as data in an=0A= SSH message.=0A= =0A= 5.3. Establishing a Session=0A= =0A= The Secure Shell Transport Model provides the following application=0A= service interface (ASI) to describe the data passed between the SSH=0A= Transport Model and the SSH service. It is an implementation=0A= decision how such data is passed.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 17]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= statusInformation =3D=0A= openSession(=0A= IN destTransportAddress -- transport address to be used=0A= IN tmSecurityName -- on behalf of this principal=0A= IN maxMessageSize -- of the sending SNMP entity=0A= )=0A= =0A= =0A= The following describes the procedure to follow to establish a=0A= session between a client and server to run SNMP over SSH. This=0A= process is used by any SNMP engine establishing a session for=0A= subsequent use.=0A= =0A= This will be done automatically for an SNMP application that=0A= initiates a transaction, such as a Command Generator or a=0A= Notification Originator or a Proxy Forwarder.=0A= =0A= 1) Using destTransportAddress, the client will establish an SSH=0A= transport connection using the SSH transport protocol, authenticate=0A= the server, and exchange keys for message integrity and encryption.=0A= The parameters of the transport connection and the credentials used=0A= to authenticate are provided in an implementation-dependent manner.=0A= =0A= If the attempt to establish a connection is unsuccessful, or server=0A= authentication fails, then sshtmSessionOpenErrors is incremented, and=0A= an openSession error indication is returned, and openSession=0A= processing stops.=0A= =0A= 2) Create an entry in the sshtmLCDTable:=0A= =0A= sshtmLCDTransportAddress =3D tmTransportAddress=0A= =0A= sshtmLCDSecurityName =3D tmSecurityName=0A= =0A= Using the sshtmLCDTransformPolicy, calculate the corresponding=0A= sshtmLCDPrincipal value.=0A= =0A= 3)In an implementation-specific manner, pass the sshtmLCDPrincipal to=0A= the SSH layer. The client will then invoke an SSH authentications=0A= service to authenticate the principal, such as that described in the=0A= SSH authentication protocol [RFC4252]. The credentials used to=0A= authenticate sshtmLCDPrincipal are determined in an implementation-=0A= dependent manner.=0A= =0A= If the authentication is unsuccessful, then the transport connection=0A= is closed, tmStateReference is released, the message is discarded,=0A= the sshtmSessionUserAuthFailures counter is incremented, an error=0A= indication is returned to the calling module, and processing stops=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 18]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= for this message.=0A= =0A= 4) Once the principal has been successfully authenticated, the client=0A= will invoke the "ssh- connection" service, also known as the SSH=0A= connection protocol [RFC4254].=0A= =0A= 5) After the ssh-connection service is established, the client will=0A= request a channel of type "session" in an implementation-dependent=0A= manner. If unsuccessful, the transport connection is closed,=0A= tmStateReference is released, the message is discarded, the=0A= sshtmSessionChannelOpenFailures counter is incremented, an error=0A= indication is returned to the calling module, and processing stops=0A= for this message.=0A= =0A= 6) If successful, this will result in an SSH session. Set the=0A= sshtmLCDSessionID in the corresponding entry. Increment the=0A= sshtmSessionOpens counter.=0A= =0A= 7) Once the SSH session has been established, the client will invoke=0A= SNMP as an SSH subsystem, as indicated in the "subsystem" parameter.=0A= =0A= In order to allow SNMP traffic to be easily identified and filtered=0A= by firewalls and other network devices, servers associated with SNMP=0A= entities using the Secure Shell Transport Model MUST default to=0A= providing access to the "SNMP" SSH subsystem if the SSH session is=0A= established using the IANA-assigned TCP port. Servers SHOULD be=0A= configurable to allow access to the SNMP SSH subsystem over other=0A= ports.=0A= =0A= 5.4. Closing a Session=0A= =0A= The Secure Shell Transport Model provides the following ASI to close=0A= a session:=0A= =0A= statusInformation =3D=0A= closeSession(=0A= IN tmTransportAddress -- transport address to be used=0A= IN tmSecurityName -- on behalf of this principal=0A= )=0A= =0A= =0A= =0A= The following describes the procedure to follow to close a session=0A= between a client and sever . This process is followed by any SNMP=0A= engine to close an SSH session. It is implementation-dependent when=0A= a session should be closed.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 19]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 1) Lookup the session in the sshtmLCDTable using the=0A= tmTransportAddress and tmSecurityName.=0A= =0A= 3) If there is no entry, then closeSession processing is=0A= completed.=0A= =0A= 4) Extract sshtmLCDPrincipal and sshtmLCDSessionID. Have SSH=0A= close the session. Increment the sshtmSessionCloses counter.=0A= =0A= 6. MIB Module Overview=0A= =0A= This MIB module provides management of the Secure Shell Transport=0A= Model. It defines some needed textual conventions, and some=0A= statistics.=0A= =0A= 6.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= 6.2. Textual Conventions=0A= =0A= Generic and Common Textual Conventions used in this document can be=0A= found summarized at http://www.ops.ietf.org/mib-common-tcs.html=0A= =0A= 6.3. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing the SSH Transport Model. In particular, it=0A= is assumed that an entity implementing the SSHTM-MIB will implement=0A= the SNMPv2-MIB [RFC3418], the SNMP-FRAMEWORK-MIB [RFC3411] and the=0A= SNMP-TRANSPORT-MIB [I-D.ietf-isms-tmsm].=0A= =0A= This MIB module is for managing SSH Transport Model information.=0A= This MIB module models a sample Local Configuration Datastore for the=0A= Transport Model (not for SSH or an associated security model).=0A= =0A= 6.3.1. MIB Modules Required for IMPORTS=0A= =0A= The following MIB module imports items from [RFC2578], [RFC2579],=0A= [RFC2580].=0A= =0A= This MIB module also references [RFC3490] and [RFC3986]=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 20]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= 7. MIB Module Definition=0A= =0A= =0A= SSHTM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= OBJECT-IDENTITY, mib-2, snmpDomains,=0A= Counter32=0A= FROM SNMPv2-SMI=0A= TEXTUAL-CONVENTION=0A= FROM SNMPv2-TC=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= ;=0A= =0A= sshtmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200710140000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= quittek@netlab.nec.de=0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Co-editors:=0A= David Harrington=0A= Huawei Technologies USA=0A= 1700 Alma Drive=0A= Plano Texas 75075=0A= USA=0A= +1 603-436-8634=0A= ietfdbh@comcast.net=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 21]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= =0A= =0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= jsalowey@cisco.com=0A= "=0A= DESCRIPTION "The Secure Shell Transport Model MIB=0A= =0A= Copyright (C) The IETF Trust (2007). This=0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200710140000Z"=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- ---------------------------------------------------------- --=0A= -- subtrees in the SNMP-SSH-TM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= sshtmNotifications OBJECT IDENTIFIER ::=3D { sshtmMIB 0 }=0A= sshtmObjects OBJECT IDENTIFIER ::=3D { sshtmMIB 1 }=0A= sshtmConformance OBJECT IDENTIFIER ::=3D { sshtmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= snmpSSHDomain OBJECT-IDENTITY=0A= STATUS current=0A= DESCRIPTION=0A= "The SNMP over SSH transport domain. The corresponding transport=0A= address is of type SnmpSSHAddress.=0A= =0A= When an SNMP entity uses the snmpSSHDomain transport=0A= model, it must be capable of accepting messages up to=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 22]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= and including 8192 octets in size. Implementation of=0A= larger values is encouraged whenever possible."=0A= ::=3D { snmpDomains yy }=0A= =0A= =0A= -- RFC Ed.: replace yy with IANA-assigned number and=0A= -- remove this note=0A= =0A= SnmpSSHAddress ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "1a"=0A= STATUS current=0A= DESCRIPTION=0A= "Represents either a hostname with a port number or an IP=0A= address with a port number.=0A= =0A= The hostname must be encoded in ASCII, as specified in=0A= RFC3490 (Internationalizing Domain Names in Applications)=0A= followed by a colon ':' (ASCII character 0x3A) and a=0A= decimal port number in ASCII. The name SHOULD be fully=0A= qualified whenever possible.=0A= =0A= An IPv4 address must be a dotted decimal format followed=0A= by a colon ':' (ASCII character 0x3A) and a decimal port=0A= number in ASCII.=0A= =0A= An IPv6 address must be a colon separated format,=0A= surrounded by brackets, followed by a colon ':' (ASCII=0A= character 0x3A) and a decimal port number in ASCII.=0A= =0A= Values of this textual convention may not be directly useable=0A= as transport-layer addressing information, and may require=0A= runtime resolution. As such, applications that write them=0A= must be prepared for handling errors if such values are=0A= not supported, or cannot be resolved (if resolution occurs=0A= at the time of the management operation).=0A= =0A= The DESCRIPTION clause of TransportAddress objects that may=0A= have snmpSSHAddress values must fully describe how (and=0A= when) such names are to be resolved to IP addresses and vice=0A= versa.=0A= =0A= This textual convention SHOULD NOT be used directly in=0A= object definitions since it restricts addresses to a=0A= specific format. However, if it is used, it MAY be used=0A= either on its own or in conjunction with=0A= TransportAddressType or TransportDomain as a pair.=0A= =0A= When this textual convention is used as a syntax of an=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 23]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= index object, there may be issues with the limit of 128=0A= sub-identifiers specified in SMIv2, STD 58. It is=0A= RECOMMENDED that all MIB documents using this textual=0A= convention make explicit any limitations on index=0A= component lengths that management software must observe.=0A= This may be done either by including SIZE constraints on=0A= the index components or by specifying applicable=0A= constraints in the conceptual row DESCRIPTION clause or=0A= in the surrounding documentation.=0A= "=0A= REFERENCE=0A= "RFC3896, Uniform Resource Identifier (URI): Generic Syntax"=0A= SYNTAX OCTET STRING (SIZE (1..255))=0A= =0A= =0A= -- The sshtmSession Group=0A= =0A= sshtmSession OBJECT IDENTIFIER ::=3D { sshtmObjects 1 }=0A= sshtmLCD OBJECT IDENTIFIER ::=3D { sshtmObjects 2 }=0A= =0A= sshtmSessionOpens OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request has been=0A= executed, whether it succeeded or failed.=0A= "=0A= ::=3D { sshtmSession 1 }=0A= =0A= sshtmSessionCloses OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times a closeSession() request has been=0A= executed, whether it succeeded or failed.=0A= "=0A= ::=3D { sshtmSession 2 }=0A= =0A= sshtmSessionOpenErrors OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a Session, for any reason.=0A= "=0A= ::=3D { sshtmSession 3 }=0A= =0A= sshtmSessionUserAuthFailures OBJECT-TYPE=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 24]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed due to user authentication failures.=0A= "=0A= ::=3D { sshtmSession 4 }=0A= =0A= sshtmSessionChannelOpenFailures OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed due to channel open failures.=0A= "=0A= ::=3D { sshtmSession 5 }=0A= =0A= sshtmSessionNoAvailableSessions OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an outgoing message=0A= was dropped because the same=0A= session was no longer available.=0A= "=0A= ::=3D { sshtmSession 6 }=0A= =0A= -- The table of users for the Transport Security Model=0A= -- This table can support users of multiple transport models=0A= =0A= sshtmLCDSpinLock OBJECT-TYPE=0A= SYNTAX TestAndIncr=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION "An advisory lock used to allow several cooperating=0A= Command Generator Applications to coordinate their=0A= use of facilities to alter the sshtmLCDTable.=0A= "=0A= ::=3D { sshtmLCD 1 }=0A= =0A= -- The transform policy for the SSH Transport Model=0A= =0A= sshtmLCDTransformPolicy OBJECT-TYPE=0A= SYNTAX INTEGER { default(1),=0A= private(2)=0A= }=0A= =0A= MAX-ACCESS read-write=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 25]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= STATUS current=0A= DESCRIPTION=0A= "The policy that should be used to perform transforms=0A= between the SSH identity and tmSecurityName, and vice-versa.=0A= =0A= default (1) - for incoming messages, the value passed in=0A= the user name field of SSH user_auth is assigned=0A= to both sshtmLCDSecurityName and sshtmLCDPrincipal.=0A= For outgoing messages, the value passed in tmSecurityName=0A= is assigned to both sshtmLCDSecurityName and=0A= sshtmLCDPrincipal.=0A= =0A= private (2) - use an implementation-specific mapping=0A= algorithm for the transform. If the algorithm does not yield=0A= a mapping, no entry should be created for the identity in=0A= the sshtmLCDTable. It is implementation-dependent=0A= whether a private algorithm is supported.=0A= "=0A= DEFVAL { default }=0A= ::=3D { sshtmLCD 2 }=0A= =0A= sshtmLCDTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF sshtmLCDEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The table of users configured in the SSH=0A= Transport Model Local Configuration Datastore (LCD).=0A= =0A= Rows in this table can be instantiated when an=0A= authenticated identity is passed to the transport model=0A= from SSH, and they can be instantiated by a command=0A= generator.=0A= =0A= To instantiate a new row in this table, the=0A= sshtmLCDSpinLock should be used to prevent conflicts.=0A= =0A= 1) GET(sshtmLCDSpinLock.0) and save in sValue.=0A= =0A= 2) SET(sshtmLCDSpinLock.0=3DsValue,=0A= sshtmLCDTransportAddress=3D(desired value),=0A= sshtmLCDSecurityName=3D(desired value),=0A= sshtmLCDPrincipal=3D(desired value),=0A= sshtmLCDSessionID=3DsValue,=0A= sshtmLCDStorageType=3D(desired value),=0A= sshtmLCDStatus=3DcreateAndGo)=0A= "=0A= ::=3D { sshtmLCD 3 }=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 26]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= sshtmLCDEntry OBJECT-TYPE=0A= SYNTAX sshtmLCDEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A user configured in the Local=0A= Configuration Datastore (LCD) for the SSH=0A= Transport Model.=0A= =0A= To maintain modularity of design, and to avoid=0A= side-effects, only the SSH Transport Model=0A= (or a SET operation) should modify this table.=0A= =0A= For all entries in this table, the transportDomain=0A= is snmpSSHTransportDomain, and the security level=0A= is authpriv.=0A= "=0A= INDEX { sshtmLCDTransportAddress,=0A= sshtmLCDSecurityName=0A= }=0A= ::=3D { sshtmLCDTable 1 }=0A= =0A= sshtmLCDEntry ::=3D SEQUENCE=0A= {=0A= sshtmLCDTransportAddress TransportAddress,=0A= sshtmLCDSecurityName SnmpAdminString,=0A= sshtmLCDPrincipal SnmpAdminString,=0A= sshtmLCDSessionID Integer32=0A= sshtmLCDStorageType StorageType,=0A= sshtmLCDRowStatus RowStatus=0A= }=0A= =0A= sshtmLCDTransportAddress OBJECT-TYPE=0A= SYNTAX TransportAddress=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION=0A= "This object contains a transport address.=0A= "=0A= ::=3D { sshtmLCDEntry 2 }=0A= =0A= sshtmLCDSecurityName OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A human readable string representing the user.=0A= This value is passed in tmSecurityName.=0A= =0A= The default transformation of the SSH user name to=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 27]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= tmSecurityName and vice versa is the identity function=0A= so the sshtmLCDSecurityName is usually the same as the=0A= sshtmLCDPrincipal.=0A= "=0A= ::=3D { sshtmLCDEntry 3 }=0A= =0A= sshtmLCDPrincipal OBJECT-TYPE=0A= SYNTAX SnmpAdminString (SIZE(1..32))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "A human readable string used to determine, in an=0A= implementation-dependent manner, which SSH=0A= credentials are used during authentication of the=0A= prinicipal.=0A= =0A= By default, this is the SSH user name.=0A= "=0A= ::=3D { sshtmLCDEntry 5 }=0A= =0A= sshtmLCDStorageType OBJECT-TYPE=0A= SYNTAX StorageType=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "The storage type for this conceptual row.=0A= =0A= Conceptual rows having the value readOnly, permanent,=0A= or nonVolatile must persist across reinitializations of=0A= the management subsystem.=0A= =0A= Conceptual rows having the value 'volatile' must not=0A= persist across reinitializations of the management=0A= subsystem.=0A= =0A= It is an implementation issue to decide if a SET for=0A= a readOnly or permanent row is accepted at all. In=0A= some contexts this may make sense, in others it may=0A= not. If a SET for a readOnly or permanent row is not=0A= accepted at all, then a 'wrongValue' error must be=0A= returned.=0A= "=0A= DEFVAL { volatile }=0A= ::=3D { sshtmLCDEntry 6 }=0A= =0A= sshtmLCDRowStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "The status of this conceptual row.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 28]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Until instances of all corresponding columns are=0A= appropriately configured, the value of the=0A= corresponding instance of sshtmLCDStatus=0A= is 'notReady'.=0A= =0A= The sshtmLCDPrincipal value should only be=0A= changed when the value of this object=0A= is 'active'.=0A= "=0A= ::=3D { sshtmLCDEntry 7 }=0A= =0A= -- ************************************************=0A= -- sshtmMIB - Conformance Information=0A= -- ************************************************=0A= =0A= sshtmCompliances OBJECT IDENTIFIER ::=3D { sshtmConformance 1 }=0A= =0A= sshtmGroups OBJECT IDENTIFIER ::=3D { sshtmConformance 2 }=0A= =0A= -- ************************************************=0A= -- Compliance statements=0A= -- ************************************************=0A= =0A= sshtmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for SNMP engines that support the=0A= SNMP-SSH-TM-MIB"=0A= MODULE=0A= MANDATORY-GROUPS { sshtmGroup }=0A= ::=3D { sshtmCompliances 1 }=0A= =0A= -- ************************************************=0A= -- Units of conformance=0A= -- ************************************************=0A= sshtmGroup OBJECT-GROUP=0A= OBJECTS {=0A= sshtmSessionOpens,=0A= sshtmSessionCloses,=0A= sshtmSessionOpenErrors,=0A= sshtmSessionUserAuthFailures,=0A= sshtmSessionChannelOpenFailures,=0A= sshtmSessionNoAvailableSessions,=0A= sshtmLCDSpinLock,=0A= sshtmLCDTransportAddress,=0A= sshtmLCDSecurityName,=0A= sshtmLCDPrincipal,=0A= sshtmLCDStorageType,=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 29]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= sshtmLCDRowStatus=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining=0A= information of an SNMP engine which implements the=0A= SNMP Secure Shell Transport Model.=0A= "=0A= =0A= =0A= ::=3D { sshtmGroups 2 }=0A= =0A= =0A= END=0A= =0A= =0A= 8. Operational Considerations=0A= =0A= The SSH Transport Model will likely not work in conditions where=0A= access to the CLI has stopped working. In situations where SNMP=0A= access has to work when the CLI has stopped working, a UDP transport=0A= model should be considered instead of the SSH Transport Model.=0A= =0A= The SSH Transport Model defines two well-known default ports, one for=0A= request/response traffic, and one port that listens for=0A= notifications.=0A= =0A= If the SSH Transport Model is configured to utilize AAA services,=0A= operators should consider configuring support for a local=0A= authentication mechanisms, such as local passwords, so SNMP can=0A= continue operating during times of network stress.=0A= =0A= The SSH protocol has its own windowing mechanism. RFC 4254 says: The=0A= window size specifies how many bytes the other party can send before=0A= it must wait for the window to be adjusted. Both parties use the=0A= following message to adjust the window. The SSH specifications leave=0A= it open when such window adjustment messages are created. Some=0A= implementations have been found to send window adjustment messages=0A= whenever received data has been passed to the application. Since=0A= window adjustment messages are padded, encrypted, hmac'ed, and=0A= wrapped, this results in noticeable bandwidth and processing=0A= overhead, which can be avoided by sending window adjustment messages=0A= less frequently.=0A= =0A= The SSH protocol requires the execution of CPU intensive calculations=0A= to establish a session key during session establishment. This means=0A= that short lived sessions become computationally expensive compared=0A= to USM, which does not have a notion of a session key. Other=0A= transport security protocols such as TLS support a session resumption=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 30]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= feature that allows reusing a cached session key. Such a mechanism=0A= does not exist for SSH and thus SNMP applications should keep SSH=0A= sessions for longer time periods.=0A= =0A= To initiate SSH connections, an entity must be configured with SSH=0A= client credentials and information to authenticate the server. While=0A= hosts are often configured to be SSH clients, most internetworking=0A= devices are not. To send notifications over SSHTM, the=0A= internetworking device will need to be configured to be SSH clients.=0A= How this credential configuration is done is implementation and=0A= deployment specific. A scalable IETF standard protocol for=0A= configuration or key management is RECOMMENDED.=0A= =0A= 9. Security Considerations=0A= =0A= This document describes a transport model that permits SNMP to=0A= utilize SSH security services. The security threats and how the SSH=0A= Transport Model mitigates those threats is covered in detail=0A= throughout this memo.=0A= =0A= The SSH Transport Model relies on SSH mutual authentication, binding=0A= of keys, confidentiality and integrity. Any authentication method=0A= that meets the requirements of the SSH architecture will provide the=0A= properties of mutual authentication and binding of keys. While SSH=0A= does support turning off confidentiality and integrity, they SHOULD=0A= NOT be turned off when used with the SSH Transport Model.=0A= =0A= SSHv2 provides Perfect Forward Security (PFS) for encryption keys.=0A= PFS is a major design goal of SSH, and any well-designed keyex=0A= algorithm will provide it.=0A= =0A= The security implications of using SSH are covered in [RFC4251].=0A= =0A= The SSH Transport Model has no way to verify that server=0A= authentication was performed, to learn the host's public key in=0A= advance, or verify that the correct key is being used. The SSH=0A= Transport Model simply trusts that these are properly configured by=0A= the implementer and deployer.=0A= =0A= 9.1. noAuthPriv=0A= =0A= SSH provides the "none" userauth method, which is normally rejected=0A= by servers and used only to find out what userauth methods are=0A= supported. However, it is legal for a server to accept this method,=0A= which has the effect of not authenticating the SSH client to the SSH=0A= server. Doing this does not compromise authentication of the SSH=0A= server to the SSH client, nor does it compromise data confidentiality=0A= or data integrity.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 31]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= SSH supports anonymous access. If the SSH Transport Model can=0A= extract from SSH an authenticated principal to map to securityName,=0A= then anonymous access SHOULD be supported. It is possible for SSH to=0A= skip entity authentication of the client through the "none"=0A= authentication method to support anonymous clients, however in this=0A= case an implementation MUST still support data integrity within the=0A= SSH transport protocol and provide an authenticated principal for=0A= mapping to securityName for access control purposes.=0A= =0A= The RFC 3411 architecture does not permit noAuthPriv. The SSH=0A= Transport Model SHOULD NOT be used with an SSH connection with the=0A= "none" userauth method.=0A= =0A= 9.2. Use with SNMPv1/v2c Messages=0A= =0A= The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP=0A= 74) [RFC3584] always selects the SNMPv1(1) Security Model for an=0A= SNMPv1 message, or the SNMPv2c(2) Security Model for an SNMPv2c=0A= message. When running SNMPv1/SNMPv2c over a secure transport like=0A= the SSH Transport Model, the securityName and securityLevel used for=0A= access control decisions are then derived from the community string,=0A= not the authenticated identity and securityLevel provided by the SSH=0A= Transport Model.=0A= =0A= 9.3. Skipping Public Key Verification=0A= =0A= Most key exchange algorithms are able to authenticate the SSH=0A= server's identity to the client. However, for the common case of DH=0A= signed by public keys, this requires the client to know the host's=0A= public key a priori and to verify that the correct key is being used.=0A= If this step is skipped, then authentication of the SSH server to the=0A= SSH client is not done. Data confidentiality and data integrity=0A= protection to the server still exist, but these are of dubious value=0A= when an attacker can insert himself between the client and the real=0A= SSH server. Note that some userauth methods may defend against this=0A= situation, but many of the common ones (including password and=0A= keyboard-interactive) do not, and in fact depend on the fact that the=0A= server's identity has been verified (so passwords are not disclosed=0A= to an attacker).=0A= =0A= SSH MUST NOT be configured to skip public key verification for use=0A= with the SSH Transport Model.=0A= =0A= 9.4. The 'none' MAC Algorithm=0A= =0A= SSH provides the "none" MAC algorithm, which would allow you to turn=0A= off data integrity while maintaining confidentiality. However, if=0A= you do this, then an attacker may be able to modify the data in=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 32]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= flight, which means you effectively have no authentication.=0A= =0A= SSH MUST NOT be configured using the "none" MAC algorithm for use=0A= with the SSH Transport Model.=0A= =0A= 9.5. MIB Module Security=0A= =0A= There are no management objects defined in this MIB module that have=0A= a MAX-ACCESS clause of read-write and/or read-create. So, if this=0A= MIB module is implemented correctly, then there is no risk that an=0A= intruder can alter or create any management objects of this MIB=0A= module via direct SNMP SET operations.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The readable objects in this MIB module are not sensitive.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPSec or=0A= SSH), even then, there is no control as to who on the secure network=0A= is allowed to access and GET/SET (read/change/create/delete) the=0A= objects in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410] section 8), including=0A= full support for the USM and the SSH Transport Model cryptographic=0A= mechanisms (for authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= 10. IANA Considerations=0A= =0A= IANA is requested to assign:=0A= =0A= 1. a TCP port number in the range 1..1023 in the=0A= http://www.iana.org/assignments/port-numbers registry which will=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 33]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= be the default port for SNMP over an SSH Transport Model as=0A= defined in this document,=0A= =0A= 2. an SMI number under mib-2, for the MIB module in this document,=0A= =0A= 3. an SMI number under snmpDomains, for the snmpSSHDomain,=0A= =0A= 4. "snmp" as an SSH Service Name in the=0A= http://www.iana.org/assignments/ssh-parameters registry.=0A= =0A= 11. Acknowledgements=0A= =0A= The editors would like to thank Jeffrey Hutzelman for sharing his SSH=0A= insights.=0A= =0A= 12. References=0A= =0A= 12.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to=0A= Indicate Requirement Levels", BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Structure of Management=0A= Information Version 2 (SMIv2)", STD 58,=0A= RFC 2578, April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Textual Conventions for=0A= SMIv2", STD 58, RFC 2579, April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins, D., and J.=0A= Schoenwaelder, "Conformance Statements for=0A= SMIv2", STD 58, RFC 2580, April 1999.=0A= =0A= [RFC2865] Rigney, C., Willens, S., Rubens, A., and W.=0A= Simpson, "Remote Authentication Dial In User=0A= Service (RADIUS)", RFC 2865, June 2000.=0A= =0A= [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An=0A= Architecture for Describing Simple Network=0A= Management Protocol (SNMP) Management=0A= Frameworks", STD 62, RFC 3411, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple=0A= Network Management Protocol (SNMP)=0A= Applications", STD 62, RFC 3413, December 2002.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 34]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= [RFC3414] Blumenthal, U. and B. Wijnen, "User-based=0A= Security Model (USM) for version 3 of the=0A= Simple Network Management Protocol (SNMPv3)",=0A= STD 62, RFC 3414, December 2002.=0A= =0A= [RFC3418] Presuhn, R., "Management Information Base (MIB)=0A= for the Simple Network Management Protocol=0A= (SNMP)", STD 62, RFC 3418, December 2002.=0A= =0A= [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,=0A= "Internationalizing Domain Names in=0A= Applications (IDNA)", RFC 3490, March 2003.=0A= =0A= [RFC3584] Frye, R., Levi, D., Routhier, S., and B.=0A= Wijnen, "Coexistence between Version 1, Version=0A= 2, and Version 3 of the Internet-standard=0A= Network Management Framework", BCP 74,=0A= RFC 3584, August 2003.=0A= =0A= [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Protocol Architecture", RFC 4251,=0A= January 2006.=0A= =0A= [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Authentication Protocol", RFC 4252,=0A= January 2006.=0A= =0A= [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Transport Layer Protocol", RFC 4253,=0A= January 2006.=0A= =0A= [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell=0A= (SSH) Connection Protocol", RFC 4254,=0A= January 2006.=0A= =0A= [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport=0A= Subsystem for the Simple Network Management=0A= Protocol (SNMP)", draft-ietf-isms-tmsm-12 (work=0A= in progress), February 2008.=0A= =0A= 12.2. Informative References=0A= =0A= [RFC1994] Simpson, W., "PPP Challenge Handshake=0A= Authentication Protocol (CHAP)", RFC 1994,=0A= August 1996.=0A= =0A= [RFC3410] Case, J., Mundy, R., Partain, D., and B.=0A= Stewart, "Introduction and Applicability=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 35]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Statements for Internet-Standard Management=0A= Framework", RFC 3410, December 2002.=0A= =0A= [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn,=0A= G., and J. Arkko, "Diameter Base Protocol",=0A= RFC 3588, September 2003.=0A= =0A= [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,=0A= "Uniform Resource Identifier (URI): Generic=0A= Syntax", STD 66, RFC 3986, January 2005.=0A= =0A= [RFC4256] Cusack, F. and M. Forssen, "Generic Message=0A= Exchange Authentication for the Secure Shell=0A= Protocol (SSH)", RFC 4256, January 2006.=0A= =0A= [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and=0A= V. Welch, "Generic Security Service Application=0A= Program Interface (GSS-API) Authentication and=0A= Key Exchange for the Secure Shell (SSH)=0A= Protocol", RFC 4462, May 2006.=0A= =0A= [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D.,=0A= Williams, D., and W. Beck, "RADIUS Extension=0A= for Digest Authentication", RFC 5090,=0A= February 2008.=0A= =0A= [RFC4742] Wasserman, M. and T. Goddard, "Using the=0A= NETCONF Configuration Protocol over Secure=0A= SHell (SSH)", RFC 4742, December 2006.=0A= =0A= Appendix A. Open Issues=0A= =0A= We need to reach consensus on some issues.=0A= =0A= Here is the current list of issues from the SSH Transport Model=0A= document where we need to reach consensus.=0A= =0A= o Issue #2: In USM, there is a mapping table that permits one user=0A= to have multiple methods for authentication, that map to a common=0A= securityName. Since SSH supports multiple authentication=0A= mechanisms, do we need to specify how these mechanism-specific=0A= identities map to a common securityName? This is important to=0A= permit admins to configure the TARGET-MIB, for example, with one=0A= common identity rather than mechanism-specific identities.=0A= =0A= o Issue #3: Mapping from the sshtmLCDTable identity to an SSH=0A= mechanisms-specific identity. This may just be the opposite=0A= transform of Issue #2.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 36]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= o Issue #5: what are the elements of procedure if you run for=0A= example SNMPv3/USM over SSHTM? The ASIs do not have parameters to=0A= identify two methods of authentication, and it is unclear how an=0A= outgoing message request would specify both SNMPv3/USM and SSHTM=0A= should be used, and which securityName/Level should be used for=0A= each.=0A= =0A= o Issue #6: We have not resolved whether the principal associated=0A= with a notification receiver must be a principal (aka user) or=0A= whether a hostname is adequate. In SNMPv3, the access controls=0A= are symmetrical - it is a user-level principal that access=0A= controls apply to, whether for R/R or notify applications. Is it=0A= acceptable to have user-level for R/R and host-level for notify=0A= functionality? A user that is not allowed to GET an object might=0A= be able to have the value of the object reported in a=0A= notification, or vice-versa. This is not much different that a=0A= principal having two different identities, one for R/R and another=0A= for notifications, or an admin configuring systems to send=0A= notifications to a different principal than those who do R/R=0A= processing. The WG needs to discuss this and reach some consensus=0A= on whether this is an issue or not, and how we want to proceed.=0A= =0A= o Issue #8: Should we allow transport models to select the=0A= corresponding security model by providing an additional parameter=0A= - the securityModel parameter - to tmStateReference, which would=0A= override the securityModel parameter extracted from a message=0A= header? Doing this would resolve Issue #5, and would allow the=0A= transport security model to be used with all SNMP message=0A= versions.=0A= =0A= TODO:=0A= =0A= finalize error processing in EOP=0A= =0A= Appendix B. Change Log=0A= =0A= From -10- to -11=0A= =0A= Changed LCD to sshtmLCDTable so it would not be confused with the=0A= snmpTsmLCD.=0A= =0A= Removed the text that said the format and content of the LCD is=0A= implementation-specific, since we now have a MIB module to=0A= standardize the format and content.=0A= =0A= Added operational considerations about SSH client credential=0A= distribution.=0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 37]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Modified EOP to use sshtmLCDTable=0A= =0A= From -09- to -10=0A= =0A= Issue #1: Made release of cached session info an implementation=0A= requirement on session close.=0A= =0A= Issue #4: UTF-8 syntax of userauth user name matches syntax of=0A= SnmpAdminString.=0A= =0A= Issue #7: Resolved to not describe how an SSH session is closed.=0A= =0A= From -08- to -09=0A= =0A= Updated MIB assignment to by rfc4181 compatible=0A= =0A= update MIB security considerations with coexistence issues=0A= =0A= update sameSession and tmSessionID support=0A= =0A= Fixed note about terminology, for consistency with SNMPv3.=0A= =0A= =0A= =0A= From -07- to -08=0A= =0A= Updated MIB=0A= =0A= update MIB security considerations=0A= =0A= develop sameSession and tmSessionID support=0A= =0A= Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= Removed reference to mappings other than the identity function.=0A= =0A= From -06- to -07=0A= =0A= removed section on SSH to EngineID mappings, since engineIDs are=0A= not exposed to the transport model=0A= =0A= removed references to engineIDs and discovery=0A= =0A= removed references to securityModel.=0A= =0A= added security considerations warning about using with SNMPv1/v2c=0A= messages.=0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 38]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= added keyboard interactive discussion=0A= =0A= noted some implementation-dependent points=0A= =0A= removed references to transportModel; we use the transport domain=0A= as a model identifier.=0A= =0A= cleaned up ASIs=0A= =0A= modified MIB to be under snmpModules=0A= =0A= changed transportAddressSSH to snmpSSHDomain style addressing=0A= =0A= From -05- to -06=0A= =0A= replaced transportDomainSSH with RFC3417-style snmpSSHDomain=0A= =0A= replaced transportAddressSSH with RFC3417-style snmpSSHAddress=0A= =0A= Changed recvMessage to receiveMessage, and modified OUT to IN to=0A= match TMSM.=0A= =0A= From -04- to -05=0A= =0A= added sshtmUserTable=0A= =0A= moved session tabel into the transport model MIB from the=0A= transport subsystem MIB=0A= =0A= added and then removed Appendix A - Notification Tables=0A= Configuration (see Transport Security Model)=0A= =0A= made this document a specification of a transport model, rather=0A= than a security model in two parts. Eliminated TMSP and MPSP and=0A= replaced them with "transport model" and "security model".=0A= =0A= Removed security-model-specific processing from this document.=0A= =0A= Removed discussion of snmpv3/v1/v2c message format co-existence=0A= =0A= changed tmSessionReference back to tmStateReference=0A= =0A= "From -03- to -04-"=0A= =0A= changed tmStateReference to tmSessionReference=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 39]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= "From -02- to -03-"=0A= =0A= rewrote almost all sections=0A= =0A= merged ASI section and Elements of Procedure sections=0A= =0A= removed references to the SSH user, in preference to SSH client=0A= =0A= updated references=0A= =0A= creayted a conventions section to identify common terminology.=0A= =0A= rewrote sections on how SSH addresses threats=0A= =0A= rewrote mapping SSH to engineID=0A= =0A= eliminated discovery section=0A= =0A= detailed the Elements of Procedure=0A= =0A= eliminated secrtions on msgFlags, transport parameters=0A= =0A= resolved issues of opening notifications=0A= =0A= eliminated sessionID (TMSM needs to be updated to match)=0A= =0A= eliminated use of tmsSessiontable except as an example=0A= =0A= updated Security Considerations=0A= =0A= "From -01- to -02-"=0A= =0A= Added TransportDomainSSH and Address=0A= =0A= Removed implementation considerations=0A= =0A= Changed all "user auth" to "client auth"=0A= =0A= Removed unnecessary MIB module objects=0A= =0A= updated references=0A= =0A= improved consistency of references to TMSM as architectural=0A= extension=0A= =0A= updated conventions=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 40]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= updated threats to be more consistent with RFC3552=0A= =0A= discussion of specific SSH mechanism configurations moved to=0A= security considerations=0A= =0A= modified session discussions to reference TMSM sessions=0A= =0A= expanded discussion of engineIDs=0A= =0A= wrote text to clarify the roles of MPSP and TMSP=0A= =0A= clarified how snmpv3 message parts are ised by SSHSM=0A= =0A= modified nesting of subsections as needed=0A= =0A= securityLevel used by the SSH Transport Model always equals=0A= authpriv=0A= =0A= removed discussion of using SSHSM with SNMPv1/v2c=0A= =0A= started updating Elements of Procedure, but realized missing info=0A= needs discussion.=0A= =0A= updated MIB module relationship to other MIB modules=0A= =0A= "From -00- to -01-"=0A= =0A= -00- initial draft as ISMS work product:=0A= =0A= updated references to SecSH RFCs=0A= =0A= Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19,=0A= 20, 29, 30, and 32.=0A= =0A= updated security considerations=0A= =0A= removed Juergen Schoenwaelder from authors, at his request=0A= =0A= ran the mib module through smilint=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 41]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= =0A= EMail: jsalowey@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 42]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP July 2008=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2008).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Salowey Expires January 3, 2009 [Page 43]=0A= =0C=0A= =0A= ------=_NextPart_000_0055_01C8DC6E.0C287370 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms ------=_NextPart_000_0055_01C8DC6E.0C287370-- From isms-bounces@ietf.org Thu Jul 10 14:20:40 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADBC63A6A9E; Thu, 10 Jul 2008 14:20:40 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86BBD3A6A9E for ; Thu, 10 Jul 2008 14:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] 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 IbMsTnxBqK-B for ; Thu, 10 Jul 2008 14:20:38 -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 7AC753A6A8B for ; Thu, 10 Jul 2008 14:20:38 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id oFg21Z0060S2fkCA3MLuvh; Thu, 10 Jul 2008 21:20:54 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id oMLf1Z0044HwxpC8VMLfEd; Thu, 10 Jul 2008 21:20:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=sWSkmC6A_8hRyMJpK2YA:9 a=iABciZhG1fJCxiUEfaUA:7 a=VdR5r9gkIkaoe94BSo87PU7EBcwA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: , "'tom.petch'" References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <007f01c8d5d1$01b0bc20$0601a8c0@allison> <20080627071220.GA2713@elstar.local> Date: Thu, 10 Jul 2008 17:20:39 -0400 Message-ID: <025801c8e2d2$ce1d85f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080627071220.GA2713@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjYJSxgK8qs7uzkQzGtS1DBISWDfgKq0Fxg Cc: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, June 27, 2008 3:12 AM > To: tom.petch > Cc: David Harrington; isms@ietf.org > Subject: Re: [Isms] pre-08 for TSM document > > On Tue, Jun 24, 2008 at 09:58:24AM +0200, tom.petch wrote: > > > Focussing on this I-D, you say that the TM will not alter the LCD > > table, but I think that it will struggle to read it, at least on > > inbound messages, as it cannot be sure what the securityName is and > > so cannot index into the table. It could walk the table looking for > > a matching snmpTsmLCDName ... well perhaps not. > > I fail to see why a TM needs to read the table. The TM just passes the > name provided by the transport via the tmStateReferences and TSM then > does any mappings as needed. The initial WG discussion led to a design that took a securityName and mapped it to a transport-specific ID. The discussion now makes it clearer that the securityName should map to a tmSecurityName, and then the TM needs its own table to map from tmSecurityName to a transport-specific ID. personally, I think that's more levels of mapping than we need, and all these mappings impact the predictability of the ultimate mapping from the actual security ID to securityName. > > > I assume that snmpTsmLCDName is tmSecurityName; could the names be > > more similar or is there a subtle point that I am missing in them > > being so different? Changed to snmpTsmLCDTmSecurityName > > I agree that finding good labels is important. I am not having a good > constructive idea yet... Checking RFC 3411 again, I see there it makes > a distinction between a securityName and a security ID, where the > security ID seems to be pretty close to our tmSecurityName. Dave, do > you agree with this reading of RFC3411? > > > I am concerned at the length of snmpTsmLCDName, at 32 maximum. I am > > aware of no such constraint for an SSH user name. > > Since snmpTsmLCDName is not used in an INDEX, I think we can easily > drop the length restriction. done. This might impact the default transformations, and the ultimate mapping to securityNames used in the notification configurations. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 10 14:25:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5159A3A6819; Thu, 10 Jul 2008 14:25:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512963A6819 for ; Thu, 10 Jul 2008 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 RvZUWdY6Z14X for ; Thu, 10 Jul 2008 14:25:32 -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 9763D3A67B6 for ; Thu, 10 Jul 2008 14:25:32 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id oLfK1Z0011GXsucA3MRoAG; Thu, 10 Jul 2008 21:25:48 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id oMRm1Z00D4HwxpC8TMRn3C; Thu, 10 Jul 2008 21:25:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=tLK4sgUXUZzSxM3CHrsA:9 a=HUyhj-fd0vOsNfEprkMA:7 a=WfXE0amEHsacBAQrY4_Z8VfP1dkA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <00d201c8d1f9$06f328c0$3bf780de@china.huawei.com> <00e201c8d201$b5e9ae50$3bf780de@china.huawei.com> <20080627072519.GB2713@elstar.local> Date: Thu, 10 Jul 2008 17:25:46 -0400 Message-ID: <025901c8e2d3$85581be0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080627072519.GB2713@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjYJv58duhgTKBPSmi3crRel1XynAKrGwiQ Cc: isms@ietf.org Subject: Re: [Isms] pre-08 for TSM document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, June 27, 2008 3:25 AM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] pre-08 for TSM document > > On Thu, Jun 19, 2008 at 07:43:22PM +0800, David Harrington wrote: > > > I started calling this the snmpTsmUserTable, but that could be > > misleading, so I changed it the snmpTsmLCDTable. Let me know which > > you prefer, or if you have another name you prefer. > > I find snmpTsmLCDTable too broad; the snmpTsmLCDTransformTable is also > stored in the LCD. The table really is a > snmpTsmSecurityNameMappingTable > or a snmpTsmTmMappingTable or a snmpTsmNameMappingTable. Or what about > snmpTsmTmNameTable? I am not crazy abotu any of these, so I didn't rename this yet. Personally I think we should eliminate the table anyway. > > Nits: > > - s/2007/2008/ > > - The import of TEXTUAL-CONVENTION is not used. > > - Missing dot at the end of the first sentence in section 6.3.2. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 10 15:42:55 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EE23A6843; Thu, 10 Jul 2008 15:42:55 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210BA3A68D7 for ; Thu, 10 Jul 2008 15:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 xng3F6PzOi0r for ; Thu, 10 Jul 2008 15:42:53 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id F08A63A6843 for ; Thu, 10 Jul 2008 15:42:52 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id oN1l1Z01t0QkzPwAANj88M; Thu, 10 Jul 2008 22:43:08 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id oNj71Z0034HwxpC8NNj71y; Thu, 10 Jul 2008 22:43:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=mFdw4IXFVyqcFi-ZCT8A:9 a=Whn99Z0AqDBSXmk-1ASW4d4vKuUA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Thu, 10 Jul 2008 18:43:06 -0400 Message-ID: <026301c8e2de$532945d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acji3lHs2Ze/JWIVQu+X4Jg8ri7n6g== Subject: [Isms] new drafts X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I have posted updates to transport-security-model-08 and secshell-11 documents. They should show up soon. I tried to synchronize the documents, and address all the EOP changes, but these tables and features represent a significant change from previous revisions, so I am quite sure these are no longer almost ready for WGLC. In my estimation: We have reached consensus on the need to be more explicit about what is in the LCD, so I have provided a MIB for stored information for each document. We do not seem to have reached consensus on the need for mapping tables in both TSM and SSHTM. We do not seem to have reached consensus on what info has to be in each MIB module. We have a number of "features" related to mapping, and we do not seem to have consensus on the need for these features, and whether they are new or old features. As a result, I left mapping tables in both documents so we have some common ground for discussion of each MIB module and the supported features. Personally, I think having mapping tables in both the TM and SM is overkill, and rather than simplifying SNMP by utilizing existing security, we are making it even more complex to configure, including the related notification tables. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 10 15:45:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B1E3A6A89; Thu, 10 Jul 2008 15:45:03 -0700 (PDT) X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E28A23A69D5; Thu, 10 Jul 2008 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080710224501.E28A23A69D5@core3.amsl.com> Date: Thu, 10 Jul 2008 15:45:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-11.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Transport Model for SNMP Author(s) : D. Harrington, J. Salowey Filename : draft-ietf-isms-secshell-11.txt Pages : 43 Date : 2008-07-10 This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-secshell-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-10153059.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@ietf.org Thu Jul 10 15:45:28 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D34C28C0D8; Thu, 10 Jul 2008 15:45:21 -0700 (PDT) X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EB3AF3A6A12; Thu, 10 Jul 2008 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080710224501.EB3AF3A6A12@core3.amsl.com> Date: Thu, 10 Jul 2008 15:45:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-transport-security-model-08.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Security Model for SNMP Author(s) : D. Harrington Filename : draft-ietf-isms-transport-security-model-08.txt Pages : 36 Date : 2008-07-10 This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Transport Security Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-10153113.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@ietf.org Fri Jul 11 00:29:24 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864913A6A0C; Fri, 11 Jul 2008 00:29:24 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA4E3A6A02 for ; Fri, 11 Jul 2008 00:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 F6S2+QxpnhRZ for ; Fri, 11 Jul 2008 00:29:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9ACB33A6992 for ; Fri, 11 Jul 2008 00:29:21 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F60FC0020 for ; Fri, 11 Jul 2008 09:29:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Fso5xFsd6yzs; Fri, 11 Jul 2008 09:29:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B99A7C001B; Fri, 11 Jul 2008 09:29:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0F48F6005A5; Fri, 11 Jul 2008 09:29:32 +0200 (CEST) Date: Fri, 11 Jul 2008 09:29:31 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080711072931.GB29275@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Isms] dublin meeting agenda X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am attaching the agenda for the ISMS meeting in Dublin. The main goal is to address the issues David Harrington just posted and in particular how much mapping functionality is needed and where it should be placed. If people want changes to the agenda, please let me know. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-agenda.txt" ============================================================= Integrated Security Model for SNMP WG (isms) IETF #72, Dublin THURSDAY, July 31, 2008, 1510-1610, Room Conservatory ============================================================= CHAIRS: Juergen Schoenwaelder AGENDA: 1) Agenda bashing, WG status ( 5 min) (Juergen Schoenwaelder) 2) Discussion of transport subsystem draft ( 5 min) (David Harrington) - Transport Subsystem for SNMP draft-ietf-isms-tmsm-12.txt 3) Discussion of transport security model draft (20 min) (David Harrington) - Transport Security Model for SNMP draft-ietf-isms-transport-security-model-08.txt 4) Discussion of SSH transport model draft (20 min) (David Harrington) - Secure Shell Transport Model for SNMP draft-ietf-isms-secshell-11.txt 5) Discussion of RADIUS draft ( 5 min) (David Nelson) - RADIUS Usage for SNMP SSH Security Model draft-ietf-isms-radius-usage-02.txt 6) Wrap up ( 5 min) (Juergen Schoenwaelder) - review of ISMS milestones - review of action points WG INTERNET DRAFTS: - Transport Subsystem for the Simple Network Management Protocol (SNMP) - Transport Security Model for SNMP draft-ietf-isms-transport-security-model-08.txt - Secure Shell Transport Model for SNMP draft-ietf-isms-secshell-11.txt - Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models RELATED INTERNET DRAFTS: - Simple Network Management Protocol (SNMP) Context EngineID Discovery - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management - Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP) - Datagram Transport Layer Security Transport Model for SNMP --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --Dxnq1zWXvFF0Q93v-- From isms-bounces@ietf.org Mon Jul 14 03:19:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E483F28C251; Mon, 14 Jul 2008 03:19:15 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1266B28C254 for ; Mon, 14 Jul 2008 03:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 e-3m73cYELZl for ; Mon, 14 Jul 2008 03:19:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0CDC028C250 for ; Mon, 14 Jul 2008 03:19:14 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3FAECC0033; Mon, 14 Jul 2008 12:19:39 +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 OjzFdL7ExXBq; Mon, 14 Jul 2008 12:19:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C724C0017; Mon, 14 Jul 2008 12:19:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9541360A3A8; Mon, 14 Jul 2008 12:19:33 +0200 (CEST) Date: Mon, 14 Jul 2008 12:19:33 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080714101933.GA8289@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Thu, Jul 03, 2008 at 09:43:05AM -0700, Wes Hardaker wrote: > Second, SSH has a fairly common usage that allows one user on one host to > connect as a different user on the remote host. Right now in the SSHSM > solution it's not possible to use a different remote user than the one > specified locally even though this is common usage within SSH users > today. > > To fix this, I'd like to suggest another *optional* portion on the front > of the string that allows specifying the SSH user name to be used. > Specifically, the "@" sign (ASCII 0x40) in the address string would be a > delimiter to indicate that the beginning portion is a user name. The @ > symbol don't exist legally in the existing specification so it shouldn't > conflict with the existing structure and is easy to quickly look for and > parse out. (and it is already common usage within at least some SSH > implementations). Our implementation actually support this on the command line: snmpwalk -u schoenw ssh:schoenw@host.example.com:1234 ifTable [I would prefer to get rid of the '-u schoenw' part but NET-SNMP 5.3.0.1 seems to insist on having the -u option for v3; I guess we have to dig deeper.] We currently don't implement any MIB objects but it seems straight forward and operationally useful to support the 'user@' part. So I am kind of in favour of this proposal. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 14 04:53:28 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278003A6867; Mon, 14 Jul 2008 04:53:28 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07003A6867 for ; Mon, 14 Jul 2008 04:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 J4PuSxsByJxx for ; Mon, 14 Jul 2008 04:53:25 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 3C3213A683D for ; Mon, 14 Jul 2008 04:53:25 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id pnYN1Z00U0b6N64A4ntqwo; Mon, 14 Jul 2008 11:53:50 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id pnto1Z00D4HwxpC8PntpoW; Mon, 14 Jul 2008 11:53:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=QvDTGDVsuJ4A:10 a=fF_LGgjqXxwA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=uI9UjTN1yW7X9bqdz7AA:9 a=Cne8g2oNdJksy1fAZNwA:7 a=ZxGhek6m6_cxC5sQ1vDCUYEsCXcA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Wes Hardaker'" References: <20080714101933.GA8289@elstar.local> Date: Mon, 14 Jul 2008 07:53:48 -0400 Message-ID: <065301c8e5a8$47f98360$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080714101933.GA8289@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjlmyHP8oPLlwHITtC0pdv68ooEtgAB2Ngw Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I do not support this for the current ISMS work. I am of the impression this would require yet another mapping table to support a feature that is not needed by everybody. Remember the convention that an SNMP agent should be simple, and that complexity should be handled by the manager application? This looks like something that should be supported by the manager, not by every SNMP engine. I do not think it is a lot to ask that admins use the direct name in the notify tables rather than some indirect name. We are approaching ISMS year four and we have yet to deliver a single document to the IESG. Let's not keep dreaming up additional features for unusual edge cases. Let's get our first "basic" version released so operators can use it in everyday circumstances. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Monday, July 14, 2008 6:20 AM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] Proposed SSH Transport Address Changes > (and a quick nit) > > On Thu, Jul 03, 2008 at 09:43:05AM -0700, Wes Hardaker wrote: > > > Second, SSH has a fairly common usage that allows one user > on one host to > > connect as a different user on the remote host. Right now > in the SSHSM > > solution it's not possible to use a different remote user > than the one > > specified locally even though this is common usage within SSH users > > today. > > > > To fix this, I'd like to suggest another *optional* portion > on the front > > of the string that allows specifying the SSH user name to be used. > > Specifically, the "@" sign (ASCII 0x40) in the address > string would be a > > delimiter to indicate that the beginning portion is a user > name. The @ > > symbol don't exist legally in the existing specification so > it shouldn't > > conflict with the existing structure and is easy to quickly > look for and > > parse out. (and it is already common usage within at least some SSH > > implementations). > > Our implementation actually support this on the command line: > > snmpwalk -u schoenw ssh:schoenw@host.example.com:1234 ifTable > > [I would prefer to get rid of the '-u schoenw' part but NET-SNMP > 5.3.0.1 seems to insist on having the -u option for v3; I guess we > have to dig deeper.] > > We currently don't implement any MIB objects but it seems straight > forward and operationally useful to support the 'user@' part. So I am > kind of in favour of this proposal. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 14 06:43:00 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953943A686B; Mon, 14 Jul 2008 06:43:00 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4883A686B for ; Mon, 14 Jul 2008 06:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 gBk6pw0lcTog for ; Mon, 14 Jul 2008 06:42:58 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 2E7A23A67EE for ; Mon, 14 Jul 2008 06:42:58 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 66E862C35AD; Mon, 14 Jul 2008 06:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=l6zy2aOvlWgsLVilRYj0vws8tOk=; b=AOMn GGJJGb8nBBW4ZvuVqLK6DRIoQyJAcjPTLqfoBD7QswyJV/sSkMLdQxWpWa1c+7jc mydsIkhhIlSVwq/h/r9XgGLBGecUELjFzUlAEP81kkwNlSb9ZsJj+a+qcViSbz/M 2BySmRhDkH/346w+sAjewfK0Lw1wwPpOgMxhBho= Received: by wes.hardakers.net (Postfix, from userid 274) id 1B9372C35AC; Mon, 14 Jul 2008 06:43:23 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20080714101933.GA8289@elstar.local> Date: Mon, 14 Jul 2008 06:43:22 -0700 In-Reply-To: <20080714101933.GA8289@elstar.local> (Juergen Schoenwaelder's message of "Mon, 14 Jul 2008 12:19:33 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Mon, 14 Jul 2008 12:19:33 +0200, Juergen Schoenwaelder said: JS> snmpwalk -u schoenw ssh:schoenw@host.example.com:1234 ifTable JS> [I would prefer to get rid of the '-u schoenw' part but NET-SNMP JS> 5.3.0.1 seems to insist on having the -u option for v3; I guess we JS> have to dig deeper.] echo "defSecurityName schoenw" >> ~/.snmp/snmp.conf But what I wanted to support was more like: snmpwalk -u schoenw ssh:juergen@host.example.com:1234 ifTable -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 14 06:43:45 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30253A686B; Mon, 14 Jul 2008 06:43:44 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA4B3A686B for ; Mon, 14 Jul 2008 06:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 7h9eG5yAKmxp for ; Mon, 14 Jul 2008 06:43:42 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 35DE53A67EE for ; Mon, 14 Jul 2008 06:43:42 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 1E0A02C35AD; Mon, 14 Jul 2008 06:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=tyO9DBhvASwVTiAzJXUAhQZo3Cc=; b=AVfJ WHM/QtbWS8sp3/IglmS5/8ggcfcome0f58Ta/86g0OZF6XAcYhY4dMU19mLuIYt1 a0J4S9I5n5tX38LzeTiECchbN/Xbzluv1xrANa06xnasMW7amVq/u0DPD0pZl9Fh gxRgp4btMdqt+WRG0PzdcmGfiXH/ZfliP6ypthU= Received: by wes.hardakers.net (Postfix, from userid 274) id 0544E2C35AC; Mon, 14 Jul 2008 06:44:08 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20080714101933.GA8289@elstar.local> <065301c8e5a8$47f98360$0600a8c0@china.huawei.com> Date: Mon, 14 Jul 2008 06:44:07 -0700 In-Reply-To: <065301c8e5a8$47f98360$0600a8c0@china.huawei.com> (David Harrington's message of "Mon, 14 Jul 2008 07:53:48 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Mon, 14 Jul 2008 07:53:48 -0400, "David Harrington" said: DH> I am of the impression this would require yet another mapping table to DH> support a feature that is not needed by everybody. Actually, I think it drops the need for one. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 14 06:54:17 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C777A3A6903; Mon, 14 Jul 2008 06:54:17 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936513A6954 for ; Mon, 14 Jul 2008 06:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=-0.142, 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 TjiZk5OcxMX3 for ; Mon, 14 Jul 2008 06:54:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B3A383A67EE for ; Mon, 14 Jul 2008 06:54:15 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3638FC005B; Mon, 14 Jul 2008 15:54:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id G5FkUMA08vHJ; Mon, 14 Jul 2008 15:54:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C97A1C0033; Mon, 14 Jul 2008 15:54:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5D24B60AB1A; Mon, 14 Jul 2008 15:54:35 +0200 (CEST) Date: Mon, 14 Jul 2008 15:54:35 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080714135435.GA9497@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: <20080714101933.GA8289@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Mon, Jul 14, 2008 at 06:43:22AM -0700, Wes Hardaker wrote: > >>>>> On Mon, 14 Jul 2008 12:19:33 +0200, Juergen Schoenwaelder said: > > JS> snmpwalk -u schoenw ssh:schoenw@host.example.com:1234 ifTable > > JS> [I would prefer to get rid of the '-u schoenw' part but NET-SNMP > JS> 5.3.0.1 seems to insist on having the -u option for v3; I guess we > JS> have to dig deeper.] > > echo "defSecurityName schoenw" >> ~/.snmp/snmp.conf I wanted to get rid of the security name altogether and instead let the app pick the security name from the transport specification... > But what I wanted to support was more like: > > snmpwalk -u schoenw ssh:juergen@host.example.com:1234 ifTable Not sure I understand this. For me, this means "authenticate as 'juergen' at host.example.com" but then what do I use 'schoenw' for? The TM security name is going to be 'juergen' and assuming no further mappings, this will be the securityName on the agent. So where do you think 'schoenw' is going to be used? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 15 11:37:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893483A6882; Tue, 15 Jul 2008 11:37:03 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02143A6882 for ; Tue, 15 Jul 2008 11:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 quh3mVlfAElo for ; Tue, 15 Jul 2008 11:37:01 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id BAC083A67CF for ; Tue, 15 Jul 2008 11:37:01 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id A9BB7399B91; Tue, 15 Jul 2008 11:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=5hjba5a7kKvSIiQHoYLE//LMRP0=; b=g1om B0qronHdRmuC1d1go7w42EYApqJVoxPKNxtAW1Pxkd4EBiVxQvfFbjLQGWatvD37 Oyfh3jZqMoIbWDAAZHYjHctqYQa9dvul2w51LlfFa1/MYAbwjwNvJzDPYboXovbg 7tzcZ8Gdr6MzpbwX3/LZ6aCllugPRHaUTPyBKBQ= Received: by wes.hardakers.net (Postfix, from userid 274) id 11BC5399B92; Tue, 15 Jul 2008 11:37:28 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20080714101933.GA8289@elstar.local> <20080714135435.GA9497@elstar.local> Date: Tue, 15 Jul 2008 11:37:28 -0700 In-Reply-To: <20080714135435.GA9497@elstar.local> (Juergen Schoenwaelder's message of "Mon, 14 Jul 2008 15:54:35 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Mon, 14 Jul 2008 15:54:35 +0200, Juergen Schoenwaelder said: >> echo "defSecurityName schoenw" >> ~/.snmp/snmp.conf JS> I wanted to get rid of the security name altogether and instead let JS> the app pick the security name from the transport specification... >From a technical point of view, it doesn't mater where you specify the security name that the Net-SNMP transport handler gets the name it's supposed to use. However, from a following-the-specs point of view passing it in via the session makes more sense for what gets mapped to the session's securityName to use. The openSession ASI, for example, expects the session's securityName to be passed as a separate parameter from the address (this cut-n-paste is from the secshell draft, though it exists in others too): openSession( IN destTransportAddress -- transport address to be used IN tmSecurityName -- on behalf of this principal IN maxMessageSize -- of the sending SNMP entity ) Thus having the securityName passed in via a session parameter more closely mimics the ASI. >> snmpwalk -u schoenw ssh:juergen@host.example.com:1234 ifTable JS> Not sure I understand this. For me, this means "authenticate as JS> 'juergen' at host.example.com" but then what do I use 'schoenw' for? JS> The TM security name is going to be 'juergen' and assuming no further JS> mappings, this will be the securityName on the agent. So where do you JS> think 'schoenw' is going to be used? What I was proposing is different. The passed in securityName and the securityName that would associated with the session is unmodified. It would still be "schoenw". The SSH username passed via the SSH authentication scheme would be "juergen" though, allowing the local "schoenw" user to log into "juergen" on the remote machine. This occurs all the time today when I, as "hardaker" log into another machine as "whardaker". For my proposal, only the SSH transport needs to know about the remote username in the address specification. The local session would still hold "schoenw" as the local securityName attached to the session. Without that, I agree that it's not necessary and what's the point of adding it to the address spec since another one is already passed in the openSession arguments. With it, it allows a local name to be different than the remote name (which, as I've mentioned before, is a common notion under SSH). The only real added benefit is to allow notifications to be sent to multiple remote destinations with different remote user names that are all mapped to the same VACM entries locally for notification authorization. David's already against the idea and I'm fine with dropping it as well in interest of forward progress. It's a minor twiddle to the document and I'd be happy to supply wording if support beyond myself is found. Either way, it should probably be a MAY support, IMHO. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 15 11:57:24 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318483A693A; Tue, 15 Jul 2008 11:57:24 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DED3A6959 for ; Tue, 15 Jul 2008 11:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 07zWb5jpMtlI for ; Tue, 15 Jul 2008 11:57:22 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 111923A693A for ; Tue, 15 Jul 2008 11:57:22 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id AB985399B91; Tue, 15 Jul 2008 11:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=vP/kbs/x6hAbiB00+N03o5TVM5E=; b=g7jH cID9VXj1qGllkXBu3UXBSE8NYsE5wJNs5lb972LDpa7xP64cDXW1IKET5UpgkA/D iQm/SuZXNBgrd1PtfnLHIyz1kRTppErpFCaU5AZtAeCVUrc4VWGD5ND333wLq3WA aUQbx4OygZqVbI1WfsPDIzX0KYOWcmDrLZT7dJg= Received: by wes.hardakers.net (Postfix, from userid 274) id 7457A399B92; Tue, 15 Jul 2008 11:57:47 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <20080714101933.GA8289@elstar.local> <20080714135435.GA9497@elstar.local> Date: Tue, 15 Jul 2008 11:57:47 -0700 In-Reply-To: (David B. Nelson's message of "Tue, 15 Jul 2008 14:48:42 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Tue, 15 Jul 2008 14:48:42 -0400, "David B. Nelson" said: DBN> I thought a major initiative of the ISMS work was to create a path DBN> to independence from this sort of dependency. SSH users do use this sort of feature today (the difference is that the authorization is performed always at the logged-into-site, unlike SNMP notifications). Regardless of whether it scales wonderfully or not, it's common syntax that SSH users know and possibly expect. The goal of the ISMS working group was to give them what they know. DBN> In an AAA-driven environment, the idea is to use the *same* user identity DBN> (username) always and everywhere. You're right: no one should mandate that they use it. (it's when infrastructures collide that people frequently use it. I do have infrastructure I make use of with SSH that I can't change my username account on to match what I am personally using everywhere else) -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 15 12:06:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253B13A68CD; Tue, 15 Jul 2008 12:06:36 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D163A68CD for ; Tue, 15 Jul 2008 12:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 uKHhbrW8malw for ; Tue, 15 Jul 2008 12:06:34 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D542F3A6823 for ; Tue, 15 Jul 2008 12:06:33 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D18EE399B91; Tue, 15 Jul 2008 12:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=EhskPq4evQaNz+mt1JzTXc5I28M=; b=B5IT ZuVVlhRzgVCAyITuzgZrazcQwANjsmEDt2BVYNQ6TXB7ilUzRGQhMEpuL7FxBtr+ dG91tBXwu++L6OANpPBt1dpWv7ZX3oNJvZhBT2AUkGudFzLcQJcUaGX+60SyLsr8 5rESKbzzGFziYa6x1SJfSL51ORveQFEe/8h3rcY= Received: by wes.hardakers.net (Postfix, from userid 274) id 8B7E0399B92; Tue, 15 Jul 2008 12:07:01 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <20080714101933.GA8289@elstar.local> <20080714135435.GA9497@elstar.local> <8852D8C172F740E69C47182D98E355B3@xpsuperdvd2> Date: Tue, 15 Jul 2008 12:06:59 -0700 In-Reply-To: <8852D8C172F740E69C47182D98E355B3@xpsuperdvd2> (David B. Nelson's message of "Tue, 15 Jul 2008 15:03:24 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Tue, 15 Jul 2008 15:03:24 -0400, "David B. Nelson" said: DBN> I realize that "single sign-on" (i.e. universal AAA) is like the DBN> "Holy Grail" (much coveted, but never to be obtained). However, DBN> that fact that we don't have it continually irritates me, on a DBN> personal level. It's what you would call a "pet peeve". :-) Yep. I've spent many years trying to pick up the holy grail of single signon. The problem is that every time I pick up a grail, someone taps me on the shoulder and hands me another one. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 15 12:29:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69BE3A6877; Tue, 15 Jul 2008 12:29:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307453A68E8 for ; Tue, 15 Jul 2008 12:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_50=0.001] 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 g42tEVIh61jR for ; Tue, 15 Jul 2008 12:29:45 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 51F103A6877 for ; Tue, 15 Jul 2008 12:29:44 -0700 (PDT) Received: (qmail 735 invoked from network); 15 Jul 2008 15:03:28 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 15 Jul 2008 15:03:28 -0400 From: "David B. Nelson" To: References: <20080714101933.GA8289@elstar.local><20080714135435.GA9497@elstar.local> Date: Tue, 15 Jul 2008 15:03:24 -0400 Organization: Elbrys Networks, Inc. Message-ID: <8852D8C172F740E69C47182D98E355B3@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjmrKzsuuf1XcSTQzyLIZu1gaUl+gAADteQ In-Reply-To: Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker writes... > (it's when infrastructures collide that people frequently use it. > I do have infrastructure I make use of with SSH that I can't > change my username account on to match what I am personally using > everywhere else) I realize that "single sign-on" (i.e. universal AAA) is like the "Holy Grail" (much coveted, but never to be obtained). However, that fact that we don't have it continually irritates me, on a personal level. It's what you would call a "pet peeve". :-) _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 15 12:48:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462513A6AF6; Tue, 15 Jul 2008 12:48:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0D6A3A6AF6 for ; Tue, 15 Jul 2008 12:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=1.151, 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 Y2jLECg5vE8F for ; Tue, 15 Jul 2008 12:48:24 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id D9FF93A687F for ; Tue, 15 Jul 2008 12:48:23 -0700 (PDT) Received: (qmail 422 invoked from network); 15 Jul 2008 14:48:50 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 15 Jul 2008 14:48:50 -0400 From: "David B. Nelson" To: References: <20080714101933.GA8289@elstar.local><20080714135435.GA9497@elstar.local> Date: Tue, 15 Jul 2008 14:48:42 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Acjmqdgh12/hTY90TDuwN5lELR3UuQAALL1Q In-Reply-To: Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker writes... > This occurs all the time today when I, as "hardaker" log into > another machine as "whardaker". Well, yes. There are various host-resident configuration files that make that sort of thing happen (.rhosts is but one example). I thought a major initiative of the ISMS work was to create a path to independence from this sort of dependency. A dependency that, quite frankly, has scaling issues. In an AAA-driven environment, the idea is to use the *same* user identity (username) always and everywhere. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 15 14:15:53 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF55D3A6AA3; Tue, 15 Jul 2008 14:15:53 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11643A6B21 for ; Tue, 15 Jul 2008 14:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 8T17n168Urpp for ; Tue, 15 Jul 2008 14:15:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 60EDD3A6AA3 for ; Tue, 15 Jul 2008 14:15:51 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32116C002C; Tue, 15 Jul 2008 23:16:19 +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 ScYltG+wjX1I; Tue, 15 Jul 2008 23:16:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56BF2C006C; Tue, 15 Jul 2008 23:16:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BCEDF61FAC9; Tue, 15 Jul 2008 23:16:13 +0200 (CEST) Date: Tue, 15 Jul 2008 23:16:13 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080715211613.GB16896@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: <20080714101933.GA8289@elstar.local> <20080714135435.GA9497@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] Proposed SSH Transport Address Changes (and a quick nit) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Jul 15, 2008 at 11:37:28AM -0700, Wes Hardaker wrote: > >> snmpwalk -u schoenw ssh:juergen@host.example.com:1234 ifTable > > JS> Not sure I understand this. For me, this means "authenticate as > JS> 'juergen' at host.example.com" but then what do I use 'schoenw' for? > JS> The TM security name is going to be 'juergen' and assuming no further > JS> mappings, this will be the securityName on the agent. So where do you > JS> think 'schoenw' is going to be used? > > What I was proposing is different. The passed in securityName and the > securityName that would associated with the session is unmodified. It > would still be "schoenw". > > The SSH username passed via the SSH authentication scheme would be > "juergen" though, allowing the local "schoenw" user to log into > "juergen" on the remote machine. This occurs all the time today when I, > as "hardaker" log into another machine as "whardaker". For my proposal, > only the SSH transport needs to know about the remote username in the > address specification. The local session would still hold "schoenw" as > the local securityName attached to the session. For command generators, the local security name (schoenw in the example) is kind of pointless. If I use ssh:juergen@host.example.com, then the authenticated identity on the command responder side is juergen. > The only real added benefit is to allow notifications to be sent to > multiple remote destinations with different remote user names that are > all mapped to the same VACM entries locally for notification > authorization. Yes, once we talk about notifications, things are different since access control is applied to the local user identity. > David's already against the idea and I'm fine with dropping it as > well in interest of forward progress. It's a minor twiddle to the > document and I'd be happy to supply wording if support beyond myself > is found. Either way, it should probably be a MAY support, IMHO. I am fine with being silent enough about this to get things out and to see what gets implemented and deployed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 17 15:29:02 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEC93A695B; Thu, 17 Jul 2008 15:29:02 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981033A695B for ; Thu, 17 Jul 2008 15:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 8mGzpqwcM+1n for ; Thu, 17 Jul 2008 15:29:00 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id BAC3C3A6831 for ; Thu, 17 Jul 2008 15:29:00 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id F1E1D399B91 for ; Thu, 17 Jul 2008 15:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=BVDbMRihnogeHDL+Jkb/eBYwPCA=; b=My1KcPonzJZuX3bQWITbbWw/5n0d jOVRrn9rTkBwu9fsU+iDIqvIPReWUBVseR4TONhumhULuw5+F0jUy8n0hiW56ps0 +ohQYkOXGhqfXoUyAj6s+M/fBJJeeRhYAuiZaLh3Tb1qjhs9RPcPQuv5RSvVd7CD O7cCwlvoPc4cVtE= Received: by wes.hardakers.net (Postfix, from userid 274) id D70CF399B92; Thu, 17 Jul 2008 15:29:31 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 17 Jul 2008 15:29:30 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] SNMP over DTLS draft published X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I submitted a SNMP over DTLS draft to the ID repository a little over a week ago and it is published as: http://www.ietf.org/internet-drafts/draft-hardaker-isms-dtls-tm-00.txt This document is not intended to delay in any way the existing ISMS work but a few people mentioned to me that it would be better to submit it now so it could be used as a second point of reference when evaluating the existing TM and TSM documents. Hopefully those that asked mo to submit it will find it useful in this way. For me, it has been useful to consider how a second transport fits within the model and I've been using it to help in the evaluation of the TM architectural model component and the TSM document to ensure the pieces can easily accommodate future models. I'll be posting my reviews of those documents shortly... -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 17 16:51:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336C03A69FD; Thu, 17 Jul 2008 16:51:56 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA8F3A6869 for ; Thu, 17 Jul 2008 16:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 v2MY-zrvcW8F for ; Thu, 17 Jul 2008 16:51:53 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 6C2E63A69FD for ; Thu, 17 Jul 2008 16:51:53 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id B55D8399B91 for ; Thu, 17 Jul 2008 16:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=Gs57CWwyg+Id/f0bS9mMHAXgFzw=; b=L6DH1BeOXrc1fyHWAUEalAwDJgXv xXum9ZYym9Z3nvRu4FPqnyx1kCOC3uRoFk3aiiBTgZvsV3DHgcIaER5+kwP6OPA+ vo5Wopxj0/5DnWCzqmqu9SVwgOldBcVx7iM1mqhdUr+yC4vBH9XxOVtLqSHPcR6+ Ntjl3/gkjA0K3/I= Received: by wes.hardakers.net (Postfix, from userid 274) id 6631E399B92; Thu, 17 Jul 2008 16:52:25 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Thu, 17 Jul 2008 16:52:25 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] isms-tmsm-12 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org General comments: * I think the document is very well written and should go forth ASAP. * The document sort of tries to be a generic transport document (as even the title implies) but really reads as if it applies specifically to security related transports. I don't think this is a problem, per say, but at one point I thought the goal was to document the definition of what a transport should take regardless of its security properties. A lot of the document discusses things in a security transport specific way. Not worth changing anything, IMHO, though. * I evaluated it thinking about it in terms of the SNMP/DTLS draft I recently published to see if both that draft and this one worked well together, and I'm happy to say it does and if anything, this document made me write down some notes to check about needed statements in the DTLS document! Section 1.2, first paragraph after the diagram: OLD: The transport mappings defined in RFC3417 do not provide lower-layer security functionality, and thus do not provide transport-specific security parameters. This document updates RFC3411 and RFC3417 by defining an architectural extension and ASIs that transport mappings (models) can use to pass transport-specific security parameters to other subsystems, including transport-specific security parameters translated into transport-independent securityName and securityLevel parameters NEW: The transport mappings defined in RFC3417 do not provide lower-layer security functionality, and thus do not provide transport-specific security parameters. This document updates RFC3411 and RFC3417 by defining an architectural extension and ***modifies the*** ASIs that transport mappings ***DELETE:(models)*** can use to pass transport-specific security parameters to other subsystems, including transport-specific security parameters ***that are*** translated into ***the*** transport-independent securityName and securityLevel parameters I'd stick with just "mappings" or "models" for statements like that to reduce terminology confusion. Having both sounds kind of confusing. (And the problem is that the older "mappings" would technically be defined as new "models"). Section 2, last sentence: * Delete "(or models)" I think it only adds confusion Section 1.3, second paragraph: * One thought would be using Must, Should and May to indicate RFC34111 compatibility. Section 2, 4th paragraph last sentence: OLD: The more important issue is that operators wanted to leverage a single user base that wasn't specific to SNMP. NEW: The more important issue is that operators wanted to leverage ***existing user base infrastructures that weren't*** specific to SNMP. rational: I don't think they necessarily wanted a single user base; they wanted their user base. EG, If you offered them a method to use USM logins on their systems in order to provide a single login database, I don't think they'd be happy even though they were provided a single database to maintain. Section 2, paragraph 7, last sentence: OLD: The use of security services provided by lower layers is the approach commonly used for the CLI, and is also the approach being proposed for NETCONF [RFC4741]. NEW: The use of security services provided by lower layers is the approach commonly used for the CLI, and is also the approach being proposed for ***other network management protocols*** NETCONF [RFC4741]. Section 3.1.1, 3rd P, first sentence: OLD: A Transport Model SHOULD require no modifications to the underlying NEW: A Transport Model SHOULD NOT require modifications to the underlying Section 3.2.1, 2nd P, last sentence: OLD: As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. NEW: As work is being done to expand the transport***s*** to include secure transport***s***... Section 3.2.1.1, title: OLD: 3.2.1.1. Processing Differences between USM and Secure Transport NEW: 3.2.1.1. Processing Differences between USM and Secure Transport***s*** Section 3.3.1, 2nd P, last sencence: OLD: If the Transport Model cannot provide at least the requested level of security, the Transport Model SHOULD discard the message and notify the dispatcher that establishing a session and sending the message failed. NEW: If the Transport Model cannot provide at least the requested level of security, the Transport Model SHOULD discard the message and ***SHOULD*** notify the dispatcher that establishing a session and sending the message failed. Desire: separate the two different statements in that sentence and put SHOULDs on each. Section 3.3.1, 3rd P: "notify ." => "notify." (note the extra space) Section 3.3.1, 3rd P, last sentence: OLD: If a session cannot be established then the message is discarded and the dispatcher should be notified that sending the message failed. NEW: If a session cannot be established then the message is discarded and the dispatcher ***SHOULD*** be notified that sending the message failed. Section 3.3.2, 2nd P: This paragraph comes close to contradicting itself. It says that it's not recommended to base session length on an operations (IE, don't try to predict operations) and then says that predicting how to define an operation is implementation-dependent. I don't think the last sentence is needed, given the point behind the second. I suggest dropping the last one. Section 3.3.3, first P: OLD: A Transport Model session is associated with state information that is maintained for its lifetime. This state information allows for the application of various security services to multiple messages. Cryptographic keys associated with the transport session SHOULD be used to provide authentication, integrity checking, and encryption services, as needed, for data that is communicated during the session. The cryptographic protocols used to establish keys for a NEW: A Transport Model session is associated with state information that is maintained for its lifetime. This state information allows for the application of various security services to ***protect*** multiple messages. Cryptographic keys associated with ***a secure*** transport session SHOULD be used to provide authentication, integrity checking, and encryption services, as needed, for data that is communicated during the session. The cryptographic protocols used to establish keys for a Section 3.3.3, first P: Remove the _'s surrounding _within_ in the last sentence Section 3.3.3, 2nd P: OLD: A Transport Model session will have a single transportDomain, transportAddress, securityName and securityLevel associated with it. If an exchange between communicating engines requires a different securityLevel or is on behalf of a different securityName, then another session would be needed. An immediate consequence of this is that implementations SHOULD be able to maintain some reasonable number of concurrent sessions. ***Note that other transport sessions with identical values may exist. These four attributes do not imply a key that can be used to uniquely identify a session*** ADD to the end: ***Note that other transport sessions with identical values may exist. These four attributes do not imply a key that can be used to uniquely identify a session*** Section 3.3.3, last P: OLD: A Transport Model may upgrade the requested security level, i.e. noAuthNoPriv and authNoPriv MAY be sent over an authenticated and encrypted session. NEW: A Transport Model ***MAY*** upgrade the requested security level, i.e. noAuthNoPriv and authNoPriv ***may*** be sent over an authenticated and encrypted session. (the MAY is on the example, not the requirement text) Section 5.2, 1st P: OLD: stored in a cache to pass model- and mechanism-specific parameters. NEW: stored in a cache to pass model-***specific*** and mechanism-specific parameters. Obviously a nit pick for personal preference... Section 6.1, 2nd P: OLD: In the diagram in section 4.6.1 of RFC 3411, the sendMessage ASI replaces the text "Send SNMP Request Message to Network". In section 4.6.2, the sendMessage ASI replaces the text "Send SNMP Message to Network" NEW: In the diagram in section 4.6.1 of RFC 3411, ***this document's*** sendMessage ASI replaces the text "Send SNMP Request Message to Network". In section 4.6.2, ***this document's*** sendMessage ASI replaces the text "Send SNMP Message to Network" Section 6.2: Comment: it's a bit odd that the only two not shown were the generateRequestMsg and generateResponseMsg... Why not just show them? Section 6.3: OLD: In the diagram in section 4.6.1 of RFC 3411, the receiveMessage ASI replaces the text "Receive SNMP Response Message from Network". In section 4.6.2, the receiveMessage ASI replaces the text "Receive SNMP Message from Network" NEW: In the diagram in section 4.6.1 of RFC 3411, ***this document's*** receiveMessage ASI replaces the text "Receive SNMP Response Message from Network". In section 4.6.2, ***this document's*** receiveMessage ASI replaces the text "Receive SNMP Message from Network" Section 7: One thing that worries me is the following: say an application specifies a security model of TSM (with authPriv requirements) but messes up and specifies a transport domain/address of a normal UDP/IPv6 address pairing. The UDP/IPv6 address transport won't successfully decline sending the message because it doesn't meet the criteria. Note that I haven't checked to see if this is discussed in the TSM document, but maybe it should be mentioned in this one? This isn't an attack vector, mind you, but does allow an administrator to accidentally send a potentially sensitive and unencrypted packet in the clear. The other side will drop it, since the TSM will check the received securityLevel (that much I remember). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 06:38:31 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E203A691C; Wed, 23 Jul 2008 06:38:31 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0114E3A691C for ; Wed, 23 Jul 2008 06:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.081, 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 G+lPO2H5PuJ5 for ; Wed, 23 Jul 2008 06:38:24 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 6C6D73A696E for ; Wed, 23 Jul 2008 06:38:24 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA10.westchester.pa.mail.comcast.net with comcast id tNMT1Z0060ldTLk5ARejEE; Wed, 23 Jul 2008 13:38:43 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA04.westchester.pa.mail.comcast.net with comcast id tRf51Z00G24Kx1C3QRf6Aq; Wed, 23 Jul 2008 13:39:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=uafMzPwxi6VLH6gH44cA:9 a=tghQxzCk8VkW8oY0bFQA:9 a=oSTk1AnCPjUpCGqmu_A3Qg0wmNQA:4 a=QMgMR9M9BAsA:10 From: "David B. Nelson" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> Date: Wed, 23 Jul 2008 09:39:06 -0400 Message-ID: <021501c8ecc9$7ace2110$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acjsil/7boFfYuzPSeKPnCU6BCc7/wAPf54g Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman writes... > In this way, the difference between an SSH user and a TLS user > becomes very clear in VACM, and the mapping from SSH username to > securityName and back is well defined. > > Comments? That may be useful for deployments where there are distinct namespaces for SSH, TLS, Kerberos, Telnet, Unix login, and what-have-you. I'm sure there are such deployments. On the other hand, another way to address the issue of divergent namespaces is to use a single AAA service (or at least a single back-end user database) for all authentication purposes within an organization. The ability to use existing AAA infrastructures (with a common user namespace) was one of the primary goals of the ISMS work, no? Universal single sign-on s still an elusive "holy grail" but it is often achieved within the confines of a single organization. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 08:28:08 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A773A69FC; Wed, 23 Jul 2008 08:28:08 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DE113A635F for ; Wed, 23 Jul 2008 08:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 LehfRMG47Lrh for ; Wed, 23 Jul 2008 08:28:06 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id A34C73A69FC for ; Wed, 23 Jul 2008 08:28:06 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D411F399BDB; Wed, 23 Jul 2008 08:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=OOjsm4nmU2sgnIqjs7IWwjGj6Yg=; b=Jw1L gey/UWFmaq8GxTNlgPPeGt2XGdp5xlk+30z13xZ5qZuLFu4pm6zPWZQPA2rYMlqL k5V8B1EuubUAYRz8Td394yBrIMAI86cMP2uTGGCjxicPSuxPh8y6R/OCt1EvlUpG dIMdzRhNT5JiP6uJ9vLMPQK9Hg5dF321dre6/d4= Received: by wes.hardakers.net (Postfix, from userid 274) id A2ADA399BDC; Wed, 23 Jul 2008 08:28:49 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <021501c8ecc9$7ace2110$6401a8c0@NEWTON603> Date: Wed, 23 Jul 2008 08:28:49 -0700 In-Reply-To: <021501c8ecc9$7ace2110$6401a8c0@NEWTON603> (David B. Nelson's message of "Wed, 23 Jul 2008 09:39:06 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 23 Jul 2008 09:39:06 -0400, "David B. Nelson" said: DBN> The ability to use existing AAA infrastructures (with a common user DBN> namespace) was one of the primary goals of the ISMS work, no? The goal was to use the infrastructure pieces that the operators were already using, which may include AAA infrastructures if they use them (but not everyone does). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 10:07:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF97D3A6A12; Wed, 23 Jul 2008 10:07:06 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A2B3A6818 for ; Wed, 23 Jul 2008 10:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 1LsSMZNScUzh for ; Wed, 23 Jul 2008 10:07:05 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 5E8D73A6407 for ; Wed, 23 Jul 2008 10:07:05 -0700 (PDT) X-Trace: 5664803/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.134.171 X-SBRS: None X-RemoteIP: 62.188.134.171 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEAD0Ch0g+vIar/2dsb2JhbACDXTWHV6coAw X-IronPort-AV: E=Sophos;i="4.31,239,1215385200"; d="scan'208";a="5664803" X-IP-Direction: IN Received: from 1cust171.tnt5.lnd4.gbr.da.uu.net (HELO allison) ([62.188.134.171]) by smtp.pipex.tiscali.co.uk with SMTP; 23 Jul 2008 18:07:45 +0100 Message-ID: <001501c8ecdd$6ac6cc40$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <026301c8e2de$532945d0$0600a8c0@china.huawei.com> Date: Wed, 23 Jul 2008 17:25:20 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Isms] securityName was new drafts X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "David Harrington" To: Sent: Friday, July 11, 2008 12:43 AM Subject: [Isms] new drafts > > I have posted updates to transport-security-model-08 and secshell-11 > documents. They should show up soon. Indeed they have and worth waiting for:-) > > I tried to synchronize the documents, and address all the EOP changes, > but these tables and features represent a significant change from > previous revisions, so I am quite sure these are no longer almost > ready for WGLC. > > In my estimation: > We have reached consensus on the need to be more explicit about what > is in the LCD, so I have provided a MIB for stored information for > each document. > > We do not seem to have reached consensus on the need for mapping > tables in both TSM and SSHTM. I think that this is the key, show-stopping issue that should be focussed on and driven to consensus. The idea of having a mapping, to a model-independent form - I am thinking primarily of (xxx)securityName - has been in isms from the start, if not before. I believe that it remains necessary, even if all the reasons given are not that easy to trace in the archives [eg Issue 32 October 2005]. But I have no attachment as to where it is done, so for me, a single table in the transport model would be fine. As I have said before, and still believe, the objections I have seen to this approach have been mostly based on what is done where in the architecture but I do not see that as a reason not to do it in the transport model. Tom Petch > We do not seem to have reached consensus on what info has to be in > each MIB module. > We have a number of "features" related to mapping, and we do not seem > to have consensus on the need for these features, and whether they are > new or old features. > > As a result, I left mapping tables in both documents so we have some > common ground for discussion of each MIB module and the supported > features. > > Personally, I think having mapping tables in both the TM and SM is > overkill, and rather than simplifying SNMP by utilizing existing > security, we are making it even more complex to configure, including > the related notification tables. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 10:32:13 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00FDA3A6A42; Wed, 23 Jul 2008 10:32:13 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83653A6966 for ; Wed, 23 Jul 2008 10:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 GMCeFqf1Z2pB for ; Wed, 23 Jul 2008 10:32:11 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 043643A6A42 for ; Wed, 23 Jul 2008 10:32:11 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id tPb91Z00B0FhH24A9VYu26; Wed, 23 Jul 2008 17:32:54 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id tVYr1Z00B4HwxpC8UVYsyg; Wed, 23 Jul 2008 17:32:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=7Bz6O23TO5Sz0p-t4yoA:9 a=f17iSTHrMroLB77jAswA:9 a=rpdzEg41L0TNAHLFnNAA:7 a=Z3UKwfsbxgJi5133aTrd01USJXYA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <021501c8ecc9$7ace2110$6401a8c0@NEWTON603> Date: Wed, 23 Jul 2008 13:32:51 -0400 Message-ID: <002501c8ecea$22ce31a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <021501c8ecc9$7ace2110$6401a8c0@NEWTON603> Thread-Index: Acjsil/7boFfYuzPSeKPnCU6BCc7/wAPf54gAAf63yA= Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Neither SSHTM nor TSM assume support for single sign-on across the administartive domain now. Neither SSHTM nor TSM assume lack of a single sign-on across the administartive domain now. SSHTM and TSM assume that the underlying protocols will not conflict, and, when used with SNMP, that resolution of any such conflict between secure transports should be resolved administratively by modifying the configuration of the underlying transports. SSHTM and TSM try to make it clear (and we may need to make it clearer) that if there is a conflict, then SSHTM and TSM will not resolve the problem; the administrator needs to eliminate the conflicts at the secure-transport layer (or possibly by disabling support for a specific transport model in SNMP). To not prevent such conflicts is a configuration error. I think that is a reasonable approach. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > Sent: Wednesday, July 23, 2008 9:39 AM > To: isms@ietf.org > Subject: Re: [Isms] pre11 comments > > Jeffrey Hutzelman writes... > > > In this way, the difference between an SSH user and a TLS user > > becomes very clear in VACM, and the mapping from SSH username to > > securityName and back is well defined. > > > > Comments? > > That may be useful for deployments where there are distinct > namespaces for > SSH, TLS, Kerberos, Telnet, Unix login, and what-have-you. > I'm sure there > are such deployments. On the other hand, another way to > address the issue > of divergent namespaces is to use a single AAA service (or at > least a single > back-end user database) for all authentication purposes within an > organization. The ability to use existing AAA infrastructures (with a > common user namespace) was one of the primary goals of the > ISMS work, no? > > Universal single sign-on s still an elusive "holy grail" but > it is often > achieved within the confines of a single organization. > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 10:37:58 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825A528C0D9; Wed, 23 Jul 2008 10:37:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E306A28C0D9 for ; Wed, 23 Jul 2008 10:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 aNEoiypruedM for ; Wed, 23 Jul 2008 10:37:57 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 1DFF328C0D0 for ; Wed, 23 Jul 2008 10:37:57 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id tNjW1Z0040mlR8UA9VegTv; Wed, 23 Jul 2008 17:38:40 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id tVee1Z00A4HwxpC8XVefqg; Wed, 23 Jul 2008 17:38:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=Jah9GwzzDgDfyjF0nIoA:9 a=MqnivGY_91ITpgKrgQMA:9 a=UiSfJlcBRO4d-muJmxIA:7 a=h4kc16Fl19xWUNsEgRSsr_Cy-h0A:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=qcu6gb7KVCAA:10 From: "David Harrington" To: "'Wes Hardaker'" , "'David B. Nelson'" References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu><021501c8ecc9$7ace2110$6401a8c0@NEWTON603> Date: Wed, 23 Jul 2008 13:38:38 -0400 Message-ID: <002601c8ecea$f1b9fee0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acjs2M+YHj/YT8p6Scuo0r4JHgwXHwAEWZqw Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Ideally, AAA support will be transparent to everything except the actual secure transport. The authentication protocol that SSH uses to authenticate the user should be hidden by SSH. The authentication protocol that TLS uses to authenticate the user should be hidden by TLS. The authentication protocol that uses to authenticate the user should be hidden by . SNMP should not know or care which authentication protocol is used (unless it is an SNMP-built-in algorithm like community or USM). SNMP should only care about getting an assertion that authentication has been done, and getting an identifier of the principal that was authenticated. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Wednesday, July 23, 2008 11:29 AM > To: David B. Nelson > Cc: isms@ietf.org > Subject: Re: [Isms] pre11 comments > > >>>>> On Wed, 23 Jul 2008 09:39:06 -0400, "David B. Nelson" > said: > > DBN> The ability to use existing AAA infrastructures (with a > common user > DBN> namespace) was one of the primary goals of the ISMS work, no? > > The goal was to use the infrastructure pieces that the operators were > already using, which may include AAA infrastructures if they use them > (but not everyone does). > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 12:43:45 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6823A6918; Wed, 23 Jul 2008 12:43:45 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88CA3A68E4 for ; Wed, 23 Jul 2008 12:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=1.036, 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 tmYqAHJOKKLX for ; Wed, 23 Jul 2008 12:43:43 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id C27523A6A37 for ; Wed, 23 Jul 2008 12:43:41 -0700 (PDT) Received: (qmail 16431 invoked from network); 23 Jul 2008 14:44:17 -0400 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.1) by gumby.elbrysnetworks.com with SMTP; 23 Jul 2008 14:44:17 -0400 Message-ID: <48877BFF.2000602@elbrysnetworks.com> Date: Wed, 23 Jul 2008 14:44:15 -0400 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: isms@ietf.org References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu><021501c8ecc9$7ace2110$6401a8c0@NEWTON603> <002601c8ecea$f1b9fee0$0600a8c0@china.huawei.com> In-Reply-To: <002601c8ecea$f1b9fee0$0600a8c0@china.huawei.com> Subject: [Isms] Multi-namespace authentication (was Re: pre11 comments) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington wrote: > Ideally, AAA support will be transparent to everything except the > actual secure transport. > SNMP should not know or care which authentication protocol is used > (unless it is an SNMP-built-in algorithm like community or USM). > SNMP should only care about getting an assertion that authentication > has been done, and getting an identifier of the principal that was > authenticated. and also... > SSHTM and TSM assume that the underlying protocols will not conflict, > and, when used with SNMP, that resolution of any such conflict between > secure transports should be resolved administratively by modifying the > configuration of the underlying transports. I think that's the correct model for SNMP, given its strong "separation of concerns" and modular architecture. However, if an operator is using *both* SSH and TLS, for example, with disjoint user databases having disjoint namespaces, the only ways to fix that issue "in the transport" would be to either synchronize the namespaces (i.e. either de jure or de facto single-sign on) or to incorporate some form of administrative "realm" element in the user name. An example of such a construct may be found in the Network Access identifier [RFC 4282]. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 14:42:32 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C443A681A; Wed, 23 Jul 2008 14:42:32 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42FA3A6922 for ; Tue, 22 Jul 2008 23:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 GVKJ4orPtVH8 for ; Tue, 22 Jul 2008 23:06:42 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id B37B23A6946 for ; Tue, 22 Jul 2008 23:06:42 -0700 (PDT) Received: from atlantis.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6N67M8J002872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 02:07:22 -0400 (EDT) Date: Wed, 23 Jul 2008 02:07:22 -0400 From: Jeffrey Hutzelman To: "David B. Nelson" , isms@ietf.org Message-ID: In-Reply-To: <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Mailman-Approved-At: Wed, 23 Jul 2008 14:42:30 -0700 Cc: jhutz@cmu.edu Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, July 03, 2008 08:57:08 PM -0400 "David B. Nelson" wrote: > 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". Actually, no. We started out with an SSH-specific security model and transport mapping, which were designed to be used together to fit within the SNMP architecture. The decision to make TSM generic was made later, when we noticed that there wasn't actually anything SSH-specific in it. I'm inclined to agree with Wes here, that it is desirable for the access control model to be able to make decisions based not only on the securityName but on the underlying security mechanism, which in the case of TSM depends on the transport model used. This isn't just about saying you trust TLS more or less than SSH. It's also about TLS, SSH, and other transport models having different namespaces, just as USM has a namespace different from any of these. If we can provide a standardized way to say "the SSH user X" at the access control level, just as we have a standardized way to say "the USM user Y", then I think we have made significant progress. I would note that it is not necessary to extend this to particular ciphers, as those do not affect the meaning of an SSH username or of the identity information in a certificate. Similarly, it does not even need to extend to particular SSH userauth methods, because SSH only has one namespace for usernames, and userauth methods are simply about proving that you are authorized to assume a particular requested username. Elsewhere, David Harrington writes... > The initial WG discussion led to a design that took a securityName and > mapped it to a > transport-specific ID. > > The discussion now makes it clearer that the securityName should map > to a tmSecurityName, and then the TM needs its own table to map from > tmSecurityName to a transport-specific ID. > > personally, I think that's more levels of mapping than we need, and > all these mappings impact the predictability of the ultimate mapping > from the actual security ID to securityName. I'm beginning to think that it is also more levels of mapping than we need. In order to simplify this somewhat and also address what I believe is Wes's concern (which has nothing to do with securityLevel), I'd like to propose a strawman. Specifically, I propose that for TSM, the securityName always take the form "TM:name", where TM is a token indicating the secure transport model in use and name is a transport-specific ID. Obviously we'd need an IANA registry of possible values for the TM token, and a new value would need to be allocated for each token. In this way, the difference between an SSH user and a TLS user becomes very clear in VACM, and the mapping from SSH username to securityName and back is well defined. Comments? -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 14:42:32 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45E328C1B7; Wed, 23 Jul 2008 14:42:32 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D6528C13A for ; Tue, 22 Jul 2008 23:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 2StOsxGdr0P1 for ; Tue, 22 Jul 2008 23:06:45 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id D94043A6922 for ; Tue, 22 Jul 2008 23:06:44 -0700 (PDT) Received: from atlantis.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6N67JmH002866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 02:07:20 -0400 (EDT) Date: Wed, 23 Jul 2008 02:07:19 -0400 From: Jeffrey Hutzelman To: "tom.petch" , David Harrington , isms@ietf.org Message-ID: In-Reply-To: <200807041049.m64AmpcA017835@toasties.srv.cs.cmu.edu> References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <003e01c8dcd9$efd6b9e0$0601a8c0@allison> <015001c8dcfb$10e08230$51f780de@china.huawei.com> <200807041049.m64AmpcA017835@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline X-Mailman-Approved-At: Wed, 23 Jul 2008 14:42:30 -0700 Cc: jhutz@cmu.edu Subject: Re: [Isms] SSHTM ignores securityLevel was Re: pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Friday, July 04, 2008 11:41:19 AM +0200 "tom.petch" wrote: > Right, this is where we part company. I have always believed that there > are good operational reasons for there to be multiple sessions. A change > of securityLevel means a change of session and I have always seen that as > a desirable feature eg that the mass of SNMP traffic is routine polling, > noAuthNoPriv, while third-level support sometimes use authPriv to find > and fix problems, and that it was important to keep them on separate TCP > sessions, eg lest a getBulk of the 150,000 entry routing table on one > delayed a poll on the other; or some > such. That has to do with operational use, not with security level. You get those on separate sessions by the simple fact of the third-level support person being a different client than the monitoring system that does periodic polling. > then I read that as saying that a change in securityLevel is a change in > target index which leads to a different session [which I think is a good > idea:-)]. Except that we assert that SSH sessions are always authPriv. This is a basic property of the transport; you're never going to get an SSH session that is not authPriv. You may get a session over which you receive messages whose requested securityLevel (in the SNMPv3 message) is some lower level, but the SSH session itself will _always_ be authPriv. This has been discussed several times. > If you are saying, use this 4-tuple as an index and for three > parts use an exact match while the fourth must be less or equals, then I > think that we need different words. > > Or if you are saying that the text means that the securityLevel is > ignored, then again I find that a bit of a stretch. These are actually exactly the same thing, because the SSH session will always be authPriv. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 15:23:44 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C0343A6B14; Wed, 23 Jul 2008 15:23:44 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3043A6B13 for ; Wed, 23 Jul 2008 15:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 339JzstO2foj for ; Wed, 23 Jul 2008 15:23:41 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 683D43A6781 for ; Wed, 23 Jul 2008 15:23:41 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 13C7B399BDB; Wed, 23 Jul 2008 15:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=33JP4Y5SkXpq24pJW+5y8dftZ0Q=; b=eOmc UXMK9ofzGEGK6W2fir6GZzoxHmjujMnTM3pNPRucm/7DRTsuwuFstjQfgOON2NoB yS2OfDX627AH09t/IZYNk9EiiZeuWhzaEt4aldlL4O+mn4wdIqXk2fkjEfbIfyLY MP9f6aLB0h+A3n9eyPkX+XnRKidTwKYF/8zYY/o= Received: by wes.hardakers.net (Postfix, from userid 274) id E68F0399BDC; Wed, 23 Jul 2008 15:24:24 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <021501c8ecc9$7ace2110$6401a8c0@NEWTON603> <002601c8ecea$f1b9fee0$0600a8c0@china.huawei.com> <48877BFF.2000602@elbrysnetworks.com> Date: Wed, 23 Jul 2008 15:24:24 -0700 In-Reply-To: <48877BFF.2000602@elbrysnetworks.com> (David B. Nelson's message of "Wed, 23 Jul 2008 14:44:15 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Multi-namespace authentication X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 23 Jul 2008 14:44:15 -0400, "David B. Nelson" said: DBN> However, if an operator is using *both* SSH and TLS, for example, with DBN> disjoint user databases having disjoint namespaces, the only ways to DBN> fix that issue "in the transport" would be to either synchronize the DBN> namespaces (i.e. either de jure or de facto single-sign on) or to DBN> incorporate some form of administrative "realm" element in the user DBN> name. An example of such a construct may be found in the Network DBN> Access identifier [RFC 4282]. And a solution like that makes sense. If every secure TM transport had to hand up a securityName from below formatted something like "user@TMTOKEN" where TMTOKEN was SSH, DTLS, TLS or whatever was defined by the TM transport then it would solve the uniqueness problem in a very very easy way. Then, if that was objectionable because people wanted a merged database the TSM mib could have a single scalar that would enable "strip all domain suffixes" to flatten the name space. A single TruthValue configurable variable is a pretty simplistic model ;-) The downside of it is that you loose a bit of the 32 octet admin securityName string length to include the @ sign and the TM suffix (and for that reason, I'd suggest very short names like "ssh", "dtls", etc). Unfortunately, RFC4282 probably isn't quiet right since it A) requires string lengths of up to 72 octets which is longer than SNMP can handle and B) is really designed for distinguishing realms (example.com) not protocols (ssh), which is where this is coming from. (the other option I considered was having the magic token spec to be specified in the transport domain definition, but in the end I decided the TM's should really hand it up since it otherwise requires the TSM to directly understand every TM that it might receive a message from) -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 18:19:58 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0893A6895; Wed, 23 Jul 2008 18:19:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09AA53A6895 for ; Wed, 23 Jul 2008 18:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.865, 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 SrPoXHG82Z6L for ; Wed, 23 Jul 2008 18:19:56 -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 9C3A73A6868 for ; Wed, 23 Jul 2008 18:19:53 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id tcNw1Z0100mlR8UA3dLZBF; Thu, 24 Jul 2008 01:20:34 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id tdL71Z00G24Kx1C8XdL840; Thu, 24 Jul 2008 01:20:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=i_Xk9FzIssrv09eJOaoA:9 a=Mu4QjUufu3kJry8sl-YA:9 a=6gq9koCEYCHmISHnUiyUeD3rDpsA:4 a=Y6qChIQXU1wA:10 a=5FtdkfQUxfIA:10 From: "David B. Nelson" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu><021501c8ecc9$7ace2110$6401a8c0@NEWTON603><002601c8ecea$f1b9fee0$0600a8c0@china.huawei.com><48877BFF.2000602@elbrysnetworks.com> Date: Wed, 23 Jul 2008 21:20:08 -0400 Message-ID: <003801c8ed2b$6af0c600$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjtEt80QRphqq3eRsS7P3cH6VY6wQAF+33g Subject: Re: [Isms] Multi-namespace authentication X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker writes... > Unfortunately, RFC4282 probably isn't quiet right since it A) requires > string lengths of up to 72 octets which is longer than SNMP can handle One could simply specify an NAI limited to a total length of 32 octets. > and B) is really designed for distinguishing realms (example.com) not > protocols (ssh), which is where this is coming from. A rose by any other name... While the original intent (in support of global roaming) was to use FQDNs as the realm identifier, there is nothing inherent in the syntax of the NAI that *requires* that to be the choice. We could easily substitute protocol "tags". _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jul 23 19:32:55 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30213A6868; Wed, 23 Jul 2008 19:32:55 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695253A677C for ; Wed, 23 Jul 2008 19:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.961 X-Spam-Level: X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 W18evjG8bw59 for ; Wed, 23 Jul 2008 19:32:53 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 8F1DF3A6805 for ; Wed, 23 Jul 2008 19:32:53 -0700 (PDT) Received: from atlantis.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6O2XQZm010942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 22:33:27 -0400 (EDT) Date: Wed, 23 Jul 2008 22:33:26 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , "David B. Nelson" Message-ID: <1F98F2BBD98CA94CEF96C69D@atlantis.pc.cs.cmu.edu> In-Reply-To: <200807232224.m6NMOTES015809@toasties.srv.cs.cmu.edu> References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <021501c8ecc9$7ace2110$6401a8c0@NEWTON603> <002601c8ecea$f1b9fee0$0600a8c0@china.huawei.com> <48877BFF.2000602@elbrysnetworks.com> <200807232224.m6NMOTES015809@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] Multi-namespace authentication X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > DBN> However, if an operator is using *both* SSH and TLS, for example, with > DBN> disjoint user databases having disjoint namespaces, the only ways to > DBN> fix that issue "in the transport" would be to either synchronize the > DBN> namespaces (i.e. either de jure or de facto single-sign on) or to > DBN> incorporate some form of administrative "realm" element in the user > DBN> name. An example of such a construct may be found in the Network > DBN> Access identifier [RFC 4282]. > > And a solution like that makes sense. If every secure TM transport had > to hand up a securityName from below formatted something like > "user@TMTOKEN" where TMTOKEN was SSH, DTLS, TLS or whatever was defined > by the TM transport then it would solve the uniqueness problem in a very > very easy way. This is pretty much exactly what I proposed, but with a different syntax. I don't have a strong reason to prefer one syntax over the other, though I think it is slightly more intuitive not to use '@' to introduce things other than domain names. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 24 00:16:43 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7951E3A68AA; Thu, 24 Jul 2008 00:16:43 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13143A68AA for ; Thu, 24 Jul 2008 00:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 1rr-BUEsCsZy for ; Thu, 24 Jul 2008 00:16:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B40FA3A67FC for ; Thu, 24 Jul 2008 00:16:41 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 635BDC0011; Thu, 24 Jul 2008 09:17:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vFY7c-qe97k9; Thu, 24 Jul 2008 09:17:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45B4BC0047; Thu, 24 Jul 2008 09:17:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EEA34673A4B; Thu, 24 Jul 2008 09:17:19 +0200 (CEST) Date: Thu, 24 Jul 2008 09:17:19 +0200 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Message-ID: <20080724071719.GA5011@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , "David B. Nelson" , isms@ietf.org, jhutz@cmu.edu References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, Jul 23, 2008 at 02:07:22AM -0400, Jeffrey Hutzelman wrote: > [...] In order to simplify this somewhat and also address what I believe > is Wes's concern (which has nothing to do with securityLevel), I'd like > to propose a strawman. Specifically, I propose that for TSM, the > securityName always take the form "TM:name", where TM is a token > indicating the secure transport model in use and name is a > transport-specific ID. Obviously we'd need an IANA registry of possible > values for the TM token, and a new value would need to be allocated for > each token. Speaking as technical contributor... Assuming the TM allows operators to configure "name" mappings. Isn't that sufficient? Do we really have to enforce a specific mapping or are we not better served by simply discussing the issue in the documents and suggesting certain configurations options addressing the issue? For some secure transports (e.g. TLS and DTLS), there might be valid reasons to not make a difference and so I prefer a clear separation of mechanism and policy here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 24 01:03:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA5B3A6837; Thu, 24 Jul 2008 01:03:25 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21943A6837 for ; Thu, 24 Jul 2008 01:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 w5-HoRN9p0M7 for ; Thu, 24 Jul 2008 01:03:23 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id DFCDE3A67A4 for ; Thu, 24 Jul 2008 01:03:22 -0700 (PDT) Received: from atlantis.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6O83wSU019661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 04:04:00 -0400 (EDT) Date: Thu, 24 Jul 2008 04:03:58 -0400 From: Jeffrey Hutzelman To: j.schoenwaelder@jacobs-university.de, Jeffrey Hutzelman Message-ID: <153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu> In-Reply-To: <20080724071719.GA5011@elstar.local> References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <20080724071719.GA5011@elstar.local> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, July 24, 2008 09:17:19 AM +0200 Juergen Schoenwaelder wrote: > On Wed, Jul 23, 2008 at 02:07:22AM -0400, Jeffrey Hutzelman wrote: > >> [...] In order to simplify this somewhat and also address what I believe >> is Wes's concern (which has nothing to do with securityLevel), I'd like >> to propose a strawman. Specifically, I propose that for TSM, the >> securityName always take the form "TM:name", where TM is a token >> indicating the secure transport model in use and name is a >> transport-specific ID. Obviously we'd need an IANA registry of possible >> values for the TM token, and a new value would need to be allocated for >> each token. > > Speaking as technical contributor... > > Assuming the TM allows operators to configure "name" mappings. Isn't > that sufficient? Do we really have to enforce a specific mapping or > are we not better served by simply discussing the issue in the > documents and suggesting certain configurations options addressing the > issue? > > For some secure transports (e.g. TLS and DTLS), there might be valid > reasons to not make a difference and so I prefer a clear separation of > mechanism and policy here. I'm inclined to say that distinguishing between secure transports in a useful way is something that TSM must handle, just as SNMP must handle distinguishing between security models. I can see three ways to do this: (1) Wave your hands and say that TSM must magically deal with any potential conflicts, but not say how. This approach works surprisingly well for SSH and SASL, among other things, but does not lend itself to the sort of formalized, standardized configuration that people are likely to want for TSM. (2) Provide a standardized mapping table in TSM, which allows configuration of a bidirectional mapping between that TM's transport-specific ID's and the transport-independent securityName. This mapping could potentially be distinct for different TM's, or the same for all TM's, depending on the reality of the deployment. In any case, it will need to be the case that for any given (TM, transport-ID) in the table there is only one securityName, _and_ that for any given (TM, securityName) there is only one transport-ID -- you have to be able to convert in both directions, but you don't have to be able to infer a TM from a securityName, because for outgoing messages you already know what TM will be used. Naturally, the contents of this mapping table would be exposed in the TSM MIB. (3) specify a standard algorithm for transforming a transport-specific ID into a securityName and the reverse, without resorting to a mapping table. This is essentially the approach that Wes and I have both proposed, where the transport-specific ID is concatenated with a fixed token naming the TM. This makes the TM in use visible at the ACM later in a predictable way, at the expense of some flexibility. I'm inclined to prefer (3), because it works without anyone having to load configuration for every possible name, and I consider that a win. Part of the goal in using existing authentication infrastructures is avoiding having to explicitly provision every user on every device. Note that even if we go with (2), I think it is sufficient to have a single mapping table in TSM; I don't think we need an additional layer of username-mapping indirection in SSHTM or any other transport model. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 24 05:44:55 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190F828C0DE; Thu, 24 Jul 2008 05:44:55 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFC83A6976 for ; Thu, 24 Jul 2008 05:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.721, 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 ENeP2eXx-xZp for ; Thu, 24 Jul 2008 05:44:53 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id BDEF03A6905 for ; Thu, 24 Jul 2008 05:44:53 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id tmjz1Z00916AWCUA1oler7; Thu, 24 Jul 2008 12:45:38 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id told1Z00324Kx1C8Sold4u; Thu, 24 Jul 2008 12:45:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=aIsxGauf8Qzme8fQ9xoA:9 a=8MT2wRL1jJWiLHATwkcA:9 a=2cJ6Kq23eU5nidKxm-4A:7 a=7QarLajniwQrMF-xQKGbauTKFxAA:4 a=QMgMR9M9BAsA:10 From: "David B. Nelson" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <20080724071719.GA5011@elstar.local> <153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu> Date: Thu, 24 Jul 2008 08:45:38 -0400 Message-ID: <007101c8ed8b$2d913ff0$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjtY9dQeN4yVMCGRUiH4AWtYwc4YQAJgDFQ Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman writes... > I'm inclined to say that distinguishing between secure transports > in a useful way is something that TSM must handle... If so, then I think it is incumbent upon us to describe the utility obtained. I think we've dismissed the issues of differing protocols, cipher-suites, and so forth, and being irrelevant to the interests of TSM, e.g. "secure" is always "secure enough". So, that leaves us with the issue of multiple authentication mechanisms that might involve multiple user namespaces. Are there other issues we are attempting to deal with? Or are we also adding the "tag" as a "hook" to deal with possible differences that someone decides are important in the future? > (3) specify a standard algorithm for transforming a transport-specific > ID into a securityName and the reverse, without resorting to a mapping > table. Wes also suggested that this mechanism me capable of being disabled, in those deployments where no distinction is necessary or desirable. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 24 10:16:22 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D3D3A6831; Thu, 24 Jul 2008 10:16:22 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B04E3A6910 for ; Thu, 24 Jul 2008 10:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 pyu2FBCnxMk2 for ; Thu, 24 Jul 2008 10:16:20 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id E917928C0DB for ; Thu, 24 Jul 2008 10:16:10 -0700 (PDT) Received: from atlantis.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6OHGoFi006601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2008 13:16:51 -0400 (EDT) Date: Thu, 24 Jul 2008 13:16:50 -0400 From: Jeffrey Hutzelman To: "David B. Nelson" , isms@ietf.org Message-ID: In-Reply-To: <200807241246.m6OCjgDE013865@raisinbran.srv.cs.cmu.edu> References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <20080724071719.GA5011@elstar.local> <153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu> <200807241246.m6OCjgDE013865@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, July 24, 2008 08:45:38 AM -0400 "David B. Nelson" wrote: > I think we've dismissed the issues of differing protocols, cipher-suites, > and so forth, and being irrelevant to the interests of TSM, e.g. "secure" > is always "secure enough". So, that leaves us with the issue of multiple > authentication mechanisms that might involve multiple user namespaces. > Are there other issues we are attempting to deal with? Or are we also > adding the "tag" as a "hook" to deal with possible differences that > someone decides are important in the future? I think we are specifically talking about distinguishing between names in different namespaces, which is necessary because the access control model can assign different access to different principals only if it can distinguish between them. >> (3) specify a standard algorithm for transforming a transport-specific >> ID into a securityName and the reverse, without resorting to a mapping >> table. > > Wes also suggested that this mechanism me capable of being disabled, in > those deployments where no distinction is necessary or desirable. Yes. The only potential problem I see with that is that doing so changes all of the securityNames reported by TSM. That means that changing this setting may make existing access control entries using those names meaningless and/or cause other entries using unqualified names to start having effect. It also means that life is harder (but not impossible, as long as the setting is exposed in a MIB) for tools that attempt to present a user-friendly interface for managing access control, because the meanings of names they use depend on this setting. I have no position on whether the benefit of being able to turn off labelling outweighs this cost. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 24 10:38:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3003A6977; Thu, 24 Jul 2008 10:38:39 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3133A6977 for ; Thu, 24 Jul 2008 10:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=0.942, 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 3-KHW4zong-N for ; Thu, 24 Jul 2008 10:38:38 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id A27923A691D for ; Thu, 24 Jul 2008 10:38:37 -0700 (PDT) Received: (qmail 9758 invoked from network); 24 Jul 2008 13:39:20 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 24 Jul 2008 13:39:20 -0400 From: "David B. Nelson" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu><20080724071719.GA5011@elstar.local><153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu><200807241246.m6OCjgDE013865@raisinbran.srv.cs.cmu.edu> Date: Thu, 24 Jul 2008 13:39:19 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjtsRqFjDZBCX3uQ3+NRvHr1m8tAAAAimvQ Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman writes... > Yes. The only potential problem I see with that is that doing so > changes all of the securityNames reported by TSM. I think this is likely a "configure once" type of choice, but I see your point. > I have no position on whether the benefit of being able to > turn off labeling outweighs this cost. There is an "other side of the coin" type of added cost if there are multiple TMs in use, with a single namespace. In that case, each name would need to be entered twice in the VACM table(s), with differing "labels". Without labels, the names would only need to be entered once. I guess we can attempt to predict whether authentication methods using multiple namespaces would be present in the majority of deployments. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 24 13:06:43 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670CD3A68F4; Thu, 24 Jul 2008 13:06:43 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17653A67F5 for ; Thu, 24 Jul 2008 13:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 PtPGETSe4Oui for ; Thu, 24 Jul 2008 13:06:41 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 2F9773A68F4 for ; Thu, 24 Jul 2008 13:06:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SMKENWUbzHu7pDRrgRkydn0A04Wa75c2waTWI/nclM80xqv1RmHqbo41h9XfgOVw; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.206.160] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KM75E-000589-JL for isms@ietf.org; Thu, 24 Jul 2008 16:06:40 -0400 Message-ID: <002801c8edc8$d4a9d080$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu><20080724071719.GA5011@elstar.local><153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu><200807241246.m6OCjgDE013865@raisinbran.srv.cs.cmu.edu> Date: Thu, 24 Jul 2008 13:06:58 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b36a783482531b7b1b9ad15d4ce7f4380d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.206.160 Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "David B. Nelson" > To: > Sent: Thursday, July 24, 2008 10:39 AM > Subject: Re: [Isms] pre11 comments ... > There is an "other side of the coin" type of added cost if there are > multiple TMs in use, with a single namespace. In that case, each name would > need to be entered twice in the VACM table(s), with differing "labels". > Without labels, the names would only need to be entered once. ... If this group had allowed itself to address the user/group VACM mapping (which is really needed to solve the configuration problem the group is trying to address) then this would be a non-issue. (This whole process started because the provisioning of USM and VACM was perceived to be too much work. The TMs discussed here work around the provisioning of USM, but don't address the user/group mapping in VACM needed to make it actually work. Look on the bright side - if/when the WG gets around to automating the VACM user/group mapping, the problem of the differing labels will go "poof". Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jul 25 02:17:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5297C28C0EE; Fri, 25 Jul 2008 02:17:03 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373943A689D for ; Fri, 25 Jul 2008 02:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 KA3DSSBN0Vjx for ; Fri, 25 Jul 2008 02:17:01 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 2070F3A6899 for ; Fri, 25 Jul 2008 02:17:00 -0700 (PDT) X-Trace: 61715576/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.69 X-SBRS: None X-RemoteIP: 213.116.52.69 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAHY2iUjVdDRF/2dsb2JhbACDXYgQpWEBAg X-IronPort-AV: E=Sophos;i="4.31,252,1215385200"; d="scan'208";a="61715576" X-IP-Direction: IN Received: from 1cust69.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.69]) by smtp.pipex.tiscali.co.uk with SMTP; 25 Jul 2008 10:17:00 +0100 Message-ID: <00d501c8ee2d$faaadda0$0601a8c0@allison> From: "tom.petch" To: , "Jeffrey Hutzelman" References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <20080724071719.GA5011@elstar.local> Date: Fri, 25 Jul 2008 10:03:25 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Jeffrey Hutzelman" Cc: ; Sent: Thursday, July 24, 2008 9:17 AM Subject: Re: [Isms] pre11 comments > On Wed, Jul 23, 2008 at 02:07:22AM -0400, Jeffrey Hutzelman wrote: > > > [...] In order to simplify this somewhat and also address what I believe > > is Wes's concern (which has nothing to do with securityLevel), I'd like > > to propose a strawman. Specifically, I propose that for TSM, the > > securityName always take the form "TM:name", where TM is a token > > indicating the secure transport model in use and name is a > > transport-specific ID. Obviously we'd need an IANA registry of possible > > values for the TM token, and a new value would need to be allocated for > > each token. > > Speaking as technical contributor... > > Assuming the TM allows operators to configure "name" mappings. Isn't > that sufficient? Do we really have to enforce a specific mapping or > are we not better served by simply discussing the issue in the > documents and suggesting certain configurations options addressing the > issue? > I agree; TM is the place to do the mapping. This is a TM related issue and we should fix it close to where the problem arises, namely in the TM. (And, at the risk of being repetitive, there is a problem with a mapping table in the SM with the ASIs as currently defined; fixable, but requiring a change to the ASIs). Tom Petch > For some secure transports (e.g. TLS and DTLS), there might be valid > reasons to not make a difference and so I prefer a clear separation of > mechanism and policy here. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 01:55:52 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5023A6A39; Mon, 28 Jul 2008 01:55:52 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57263A68E4 for ; Mon, 28 Jul 2008 01:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, RDNS_DYNAMIC=0.1] 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 iXIXTEBUryws for ; Mon, 28 Jul 2008 01:55:45 -0700 (PDT) Received: from wes.hardakers.net (cg-nat-130-129-48-98.meeting.ietf.org [130.129.48.98]) by core3.amsl.com (Postfix) with ESMTP id 792D73A6826 for ; Mon, 28 Jul 2008 01:55:45 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id EDAFA399BDB; Mon, 28 Jul 2008 01:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=bEWEey2ZS3NlKxaLhSc3g5vKhC8=; b=Hpif kxozEHpf7TxIx+VeiBvPg/Avjvgo3bw1GBY2tiHOqI3lAX4+RLcSzFZOO19fPIJQ l4X1y12goc/NOGI3KhaUWow+gA5Cm7qUEdfjLK0PwPy+RUBqe8WiDg8ECq0G4OwN 0XiJYvj6ipl7Sj+08tt+4YF1wEswnDVHol/p4Ok= Received: by wes.hardakers.net (Postfix, from userid 274) id C8517399BDC; Mon, 28 Jul 2008 01:48:30 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <006401c8dc30$bac0af30$51f780de@china.huawei.com> <4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2> <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <20080724071719.GA5011@elstar.local> <153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu> <200807241246.m6OCjgDE013865@raisinbran.srv.cs.cmu.edu> <002801c8edc8$d4a9d080$6801a8c0@oemcomputer> Date: Mon, 28 Jul 2008 01:48:30 -0700 In-Reply-To: <002801c8edc8$d4a9d080$6801a8c0@oemcomputer> (Randy Presuhn's message of "Thu, 24 Jul 2008 13:06:58 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Thu, 24 Jul 2008 13:06:58 -0700, "Randy Presuhn" said: RP> Look on the bright side - if/when the WG gets around to automating RP> the VACM user/group mapping, the problem of the differing labels RP> will go "poof". True, unless the user name "randy" is being distributed by two different protocols but should have different access rights under one vs the other. The current discussions surround being able to separate different users from different protocols so that something configuration over some magic distribution protocol can actually work to make the problem go "poof". -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 04:20:20 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9040C3A6A3A; Mon, 28 Jul 2008 04:20:20 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEBDF3A69DF for ; Mon, 28 Jul 2008 04:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.348, 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 sz87Dm7N5I2P for ; Mon, 28 Jul 2008 04:20:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 061C83A68DE for ; Mon, 28 Jul 2008 04:19:51 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 261ABC0044; Mon, 28 Jul 2008 13:20:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HSVyyReUxclN; Mon, 28 Jul 2008 13:19:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AF12C0028; Mon, 28 Jul 2008 13:19:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DAC2B678662; Mon, 28 Jul 2008 13:19:52 +0200 (CEST) Date: Mon, 28 Jul 2008 13:19:52 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080728111952.GB7785@elstar.local> Mail-Followup-To: Wes Hardaker , Randy Presuhn , isms@ietf.org References: <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu> <20080724071719.GA5011@elstar.local> <153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu> <200807241246.m6OCjgDE013865@raisinbran.srv.cs.cmu.edu> <002801c8edc8$d4a9d080$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] pre11 comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Mon, Jul 28, 2008 at 01:48:30AM -0700, Wes Hardaker wrote: > True, unless the user name "randy" is being distributed by two different > protocols but should have different access rights under one vs the > other. The current discussions surround being able to separate > different users from different protocols so that something configuration > over some magic distribution protocol can actually work to make the > problem go "poof". I assume we more or less agree that we have to be able to differentiate between names coming from different secure transport models. Any violent disagreement with this statement? If the above is correct, then question seems to be whether a) we by default make all the names different leaving it to explicit configuration to treat them the same if needed or b) we make them by default the same leaving it to explicit configuration to make them different where needed. Is this a fair statement? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 07:02:18 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6616D3A699E; Mon, 28 Jul 2008 07:02:18 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D0C28C0F3 for ; Mon, 28 Jul 2008 07:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 tZbQoalZeSx5 for ; Mon, 28 Jul 2008 07:02:13 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id DEA343A699C for ; Mon, 28 Jul 2008 07:02:12 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA05.westchester.pa.mail.comcast.net with comcast id vPdS1Z00A0Fqzac55RyjYB; Mon, 28 Jul 2008 13:58:43 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA08.westchester.pa.mail.comcast.net with comcast id vRzC1Z00G24Kx1C3URzDzV; Mon, 28 Jul 2008 13:59:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=OdRsurTgr-gA:10 a=LxHwYsXC3gwA:10 a=MtPB4ZAxq07V4_Tn_bQA:9 a=m186_VUQJXl7gkrqNJAA:9 a=sUvSuweGrr4c8O3EBCurF0X3-WkA:4 a=C35D7iIojSgA:10 From: "David B. Nelson" To: References: <006401c8dc30$bac0af30$51f780de@china.huawei.com><4F599A473EF04ECD99F4C358B291245E@xpsuperdvd2><200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu><20080724071719.GA5011@elstar.local><153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu><200807241246.m6OCjgDE013865@raisinbran.srv.cs.cmu.edu><002801c8edc8$d4a9d080$6801a8c0@oemcomputer> Date: Mon, 28 Jul 2008 09:59:12 -0400 Message-ID: <020d01c8f0ba$1dbd55f0$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acjwj8LYZkpcqAgaT5+w8aWiGvAt2QAKXecA Subject: [Isms] Multiple user namespaces (was RE: pre11 comments) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Changing the subject line *again*... Wes Hardaker writes... > The current discussions surround being able to separate different > users from different protocols so that something configuration s/protocols/authentication mechanisms/ > over some magic distribution protocol can actually work to make > the problem go "poof". This has nothing to do with the properties of any secure transport protocol and everything to do with the practice of coupling disparate transports with disparate sources of user authentication. (The "USM Problem".) I agree that we need to find a solution, but let's lay the blame for the problem where it belongs, shall we? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 07:06:37 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1073A69DE; Mon, 28 Jul 2008 07:06:37 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED4563A69DD for ; Mon, 28 Jul 2008 07:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 Vnv11wgibcPv for ; Mon, 28 Jul 2008 07:06:30 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 079273A6895 for ; Mon, 28 Jul 2008 07:06:29 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA08.westchester.pa.mail.comcast.net with comcast id vPSc1Z00B0mv7h058S6eR9; Mon, 28 Jul 2008 14:06:38 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA11.westchester.pa.mail.comcast.net with comcast id vS6e1Z00524Kx1C3XS6efo; Mon, 28 Jul 2008 14:06:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=OdRsurTgr-gA:10 a=LxHwYsXC3gwA:10 a=6xQaEXnmeFWsnODWHxwA:9 a=ANVLhdaIKozl205iv8QA:9 a=bt0Xp6hiqTq9p_M-Ig8A:7 a=LNnrVisOFZIik3S-Kg8-4k6wbbgA:4 a=C35D7iIojSgA:10 From: "David B. Nelson" To: References: <200807040057.m640v5DL015394@grapenut.srv.cs.cmu.edu><20080724071719.GA5011@elstar.local><153AB67386CBEFDB61867CE0@atlantis.pc.cs.cmu.edu><200807241246.m6OCjgDE013865@raisinbran.srv.cs.cmu.edu><002801c8edc8$d4a9d080$6801a8c0@oemcomputer> <20080728111952.GB7785@elstar.local> Date: Mon, 28 Jul 2008 10:06:38 -0400 Message-ID: <020e01c8f0bb$274e69a0$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080728111952.GB7785@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acjwo/fuj0hiwZKeRnekwbzscYpqVwAFjHLQ Subject: [Isms] Multiple user namespaces (was RE: pre11 comments) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Changing the subject line... Juergen Schoenwaelder writes... > I assume we more or less agree that we have to be able to > differentiate between names coming from different secure transport > models. Any violent disagreement with this statement? Yes. I disagree. This has nothing to do with different secure transport models and everything to do with the underlying source of user identity. The "tagging" needed to disambiguate the usernames needs to be tied not to the protocol but to the source or identity, e.g. an administrative realm. When the source of identity is the local database of the secure transport implementation, we take the shortcut (incorrect, IMHO) of "tagging" with the protocol name. > If the above is correct, then question seems to be whether a) we by > default make all the names different leaving it to explicit > configuration to treat them the same if needed or b) we make them by > default the same leaving it to explicit configuration to make them > different where needed. Is this a fair statement? That is certainly one decision to be made. Another is the source, syntax and semantics of the "tagging" information. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 07:42:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F084428C159; Mon, 28 Jul 2008 07:42:38 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086B928C159 for ; Mon, 28 Jul 2008 07:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.261, 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 gfpaUAR1ipNV for ; Mon, 28 Jul 2008 07:42:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 11E7628C153 for ; Mon, 28 Jul 2008 07:42:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AE80C0028; Mon, 28 Jul 2008 16:42:37 +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 cxZLYcE0uPGy; Mon, 28 Jul 2008 16:42:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F01E0C0034; Mon, 28 Jul 2008 16:42:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C1A8A678B90; Mon, 28 Jul 2008 16:42:29 +0200 (CEST) Date: Mon, 28 Jul 2008 16:42:29 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20080728144229.GA8421@elstar.local> Mail-Followup-To: "David B. Nelson" , isms@ietf.org References: <20080728111952.GB7785@elstar.local> <020e01c8f0bb$274e69a0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <020e01c8f0bb$274e69a0$6401a8c0@NEWTON603> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] Multiple user namespaces (was RE: pre11 comments) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Mon, Jul 28, 2008 at 10:06:38AM -0400, David B. Nelson wrote: > > I assume we more or less agree that we have to be able to > > differentiate between names coming from different secure transport > > models. Any violent disagreement with this statement? > > Yes. I disagree. This has nothing to do with different secure transport > models and everything to do with the underlying source of user identity. > The "tagging" needed to disambiguate the usernames needs to be tied not to > the protocol but to the source or identity, e.g. an administrative realm. > When the source of identity is the local database of the secure transport > implementation, we take the shortcut (incorrect, IMHO) of "tagging" with the > protocol name. Speaking as technical contributor... Some time ago, we decided to treat SSH as a black box that delivers a name that we can later (perhaps translated) use as a securityName with securityLevel authPriv and that we do not peek into the internals of SSH to say validate the securityLevel. Are you now saying we have to peek into SSH internals to figure out which "realm" a name provided by SSH belongs to? > Another is the source, syntax and semantics of the "tagging" > information. Playing devil's advocate: Why do we need have to standardize this? As far as I can tell, the mapped name only has to be consistent with the local ACM policy. In USM, the authenticated name is usmUserName and the usmUserTable allows me to map this name to a security name. In other words, with USM I can already today map usmUserName "schoenw" to "usm:schoenw" if I like to. Likewise, with the snmpCommunityTable I can map the community string "schoenw" to "csm+schoenw" if I want to. With a mapping table in TSM, I may be able (depending on the table structure) to map "schoenw" authenticated by an SSH transport to "ssh_schoenw". Is this not good enough? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 08:31:01 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80A8628C1AF; Mon, 28 Jul 2008 08:31:01 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1FED28C1AF for ; Mon, 28 Jul 2008 08:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 BOktL8V4A3Xy for ; Mon, 28 Jul 2008 08:30:59 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id A43813A65A6 for ; Mon, 28 Jul 2008 08:30:51 -0700 (PDT) Received: (qmail 26937 invoked from network); 28 Jul 2008 11:30:58 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 28 Jul 2008 11:30:58 -0400 From: "David B. Nelson" To: References: <20080728111952.GB7785@elstar.local><020e01c8f0bb$274e69a0$6401a8c0@NEWTON603> <20080728144229.GA8421@elstar.local> Date: Mon, 28 Jul 2008 11:30:57 -0400 Organization: Elbrys Networks, Inc. Message-ID: <01F0572D5B3C4A3F96F9B3FBA9DFF78E@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjwwEHlSqSuHXvcTiOPQAbPMv/7ygABEncg In-Reply-To: <20080728144229.GA8421@elstar.local> Subject: Re: [Isms] Multiple user namespaces (was RE: pre11 comments) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Schoenwaelder writes... > Some time ago, we decided to treat SSH as a black box > that delivers a name that we can later (perhaps translated) > use as a securityName ... Are you now saying we have to > peek into SSH internals to figure out which "realm" a name > provided by SSH belongs to? I guess I'm saying that SSH should deliver a "decorated" name that contains that information. That might be out of scope for ISMS, though. It's frustrating when the architecture design is hemmed in by charter constraints. :-( In the case where the local database of the protocol is used to authenticate the user, it may be sufficient to "tag" the identity with the protocol name, as the protocol name and the namespace name are one in the same. This is common case, but by no means the most general case, however. I just want to see that whatever we specify works in the most general case. > 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). _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 09:04:08 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@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@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7BEA28C1AE for ; 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 ; 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 ; 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 To: "David B. Nelson" Message-ID: <20080728160356.GA8708@elstar.local> Mail-Followup-To: "David B. Nelson" , isms@ietf.org References: <20080728144229.GA8421@elstar.local> <01F0572D5B3C4A3F96F9B3FBA9DFF78E@xpsuperdvd2> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <01F0572D5B3C4A3F96F9B3FBA9DFF78E@xpsuperdvd2> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: isms@ietf.org Subject: Re: [Isms] Multiple user namespaces (was RE: pre11 comments) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@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 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 11:09:24 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7749628C2A4; Mon, 28 Jul 2008 11:09:24 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0863228C2A0 for ; Mon, 28 Jul 2008 11:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 OP7gnk-rjrhP for ; Mon, 28 Jul 2008 11:09:17 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id E4E3B3A6838 for ; Mon, 28 Jul 2008 11:09:16 -0700 (PDT) Received: (qmail 29853 invoked from network); 28 Jul 2008 13:09:21 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 28 Jul 2008 13:09:21 -0400 From: "David B. Nelson" To: References: <20080728144229.GA8421@elstar.local> <01F0572D5B3C4A3F96F9B3FBA9DFF78E@xpsuperdvd2> <20080728160356.GA8708@elstar.local> Date: Mon, 28 Jul 2008 13:09:20 -0400 Organization: Elbrys Networks, Inc. Message-ID: <6F61DD309E224B6FA7DE2429A0EA47D9@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: Acjwy5NHToPmfovER/yjGmA/qcTS5QACAcrg In-Reply-To: <20080728160356.GA8708@elstar.local> Subject: Re: [Isms] Multiple user namespaces X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Schoenwaelder writes... > 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 ;-). Well, perhaps. I thought part of the issue with non-deployment of SNMPv3 that we are attempting to solve was that the configuration required today *is* too complicated. > We need to figure out how we can keep simple installations > simple and put the costs on more complex installations. OK, that *sounds* good. > This might require [us] to think about a wildcarding mechanism > 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)". The issue arises when there are multiple authentication methods (i.e. multiple user namespaces). That most often occurs with there are multiple transport protocols. I think that is likely already outside the "80% rule", and that the simple case is a single protocol with a single user namespace. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 11:39:59 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A08E3A6993; Mon, 28 Jul 2008 11:39:59 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3559B3A6943 for ; Mon, 28 Jul 2008 11:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 NpXXhJaEkUlA for ; Mon, 28 Jul 2008 11:39:57 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 3A90E3A6A99 for ; Mon, 28 Jul 2008 11:39:57 -0700 (PDT) Received: (qmail 32204 invoked from network); 28 Jul 2008 14:40:05 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 28 Jul 2008 14:40:05 -0400 From: "David B. Nelson" To: References: <20080728111952.GB7785@elstar.local><020e01c8f0bb$274e69a0$6401a8c0@NEWTON603> <20080728144229.GA8421@elstar.local> Date: Mon, 28 Jul 2008 14:40:04 -0400 Organization: Elbrys Networks, Inc. Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Thread-Index: AcjwwEHlWbUOZMXLT2Wwqt4FNEO7SQAII1pQ In-Reply-To: <20080728144229.GA8421@elstar.local> Subject: Re: [Isms] Multiple user namespaces X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Allow me to clarify my remarks. > Playing devil's advocate: Why do we need have to standardize this? If any portion of the name mapping or tagging scheme is not end-user configurable, it would need to be standardized. Otherwise, the name that the ACM is confronted with may be implementation dependent. That would introduce multi-vendor interoperability issues, as the ACM table provisioning would have to take this vendor dependence into account. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 12:34:07 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0383B3A6A33; Mon, 28 Jul 2008 12:34:07 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C62A3A6A33 for ; Mon, 28 Jul 2008 12:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=0.235, 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 AyrvAzGocRck for ; Mon, 28 Jul 2008 12:34:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9B7F03A6816 for ; Mon, 28 Jul 2008 12:34:04 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AAE51C002D for ; Mon, 28 Jul 2008 21:34:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kCKPanjJIEqY; Mon, 28 Jul 2008 21:34:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E44A1C000F; Mon, 28 Jul 2008 21:34:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D43DB6794D9; Mon, 28 Jul 2008 21:34:07 +0200 (CEST) Date: Mon, 28 Jul 2008 21:34:07 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080728193407.GB9610@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Isms] note taker and jabber scribe - please volunteer X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, for the meeting on Thursday, I am looking for a note taker and a Jabber scribe. Please consider volunteering my sending me an email so that we do not loose valuable time at the start of the session. Thanks, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jul 28 16:11:43 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA22A28C1DC; Mon, 28 Jul 2008 16:11:43 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6D63A6AE2 for ; Mon, 28 Jul 2008 16:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 cmaEEOtIf4W4 for ; Mon, 28 Jul 2008 16:11:41 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 5E6483A68E4 for ; Mon, 28 Jul 2008 16:11:41 -0700 (PDT) Received: from dhcp-130-129-19-120.meeting.ietf.org ([130.129.65.37]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6SNBie3026453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2008 19:11:46 -0400 (EDT) Date: Tue, 29 Jul 2008 00:11:44 +0100 From: Jeffrey Hutzelman To: "David B. Nelson" , isms@ietf.org Message-ID: <44E2E76ACFC1F326A284FBA5@atlantis.pc.cs.cmu.edu> In-Reply-To: <200807281531.m6SFVD80014895@toasties.srv.cs.cmu.edu> References: <20080728111952.GB7785@elstar.local> <020e01c8f0bb$274e69a0$6401a8c0@NEWTON603> <20080728144229.GA8421@elstar.local> <200807281531.m6SFVD80014895@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] Multiple user namespaces (was RE: pre11 comments) X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Monday, July 28, 2008 11:30:57 AM -0400 "David B. Nelson" wrote: > Juergen Schoenwaelder writes... > >> Some time ago, we decided to treat SSH as a black box >> that delivers a name that we can later (perhaps translated) >> use as a securityName ... Are you now saying we have to >> peek into SSH internals to figure out which "realm" a name >> provided by SSH belongs to? > > I guess I'm saying that SSH should deliver a "decorated" name that > contains that information. That might be out of scope for ISMS, though. > It's frustrating when the architecture design is hemmed in by charter > constraints. :-( It is a design feature of ISMS that we delegate to SSH the entire problem of mapping names coming from potentially disparate authentication namespaces into a common namespace which is provided to us. This is a feature because SSH has to (and does) solve it anyway. If we extend this approach to every future secure transport mapping, such that all such mappings can be expected to deal with any differences or false similarities between names used by their authentication mechanisms, then we are left only with the problem of dealing with differences and/or false similarities between names provided us by different possible secure transports. One possible approach for this is to deliver to the application and access control model a securityName that consists of the name provided by the secure transport, decorated with an identifier indicating which transport's namespace it belongs to. And yes, the namespace belongs to a transport model, not to an authentication method, because it is the result of the transport model and/or the underlying transport having resolved conflicts between possible authentication methods and applied appropriate mappings. If I use SSH-gss-krb5 to log in to your ssh server, the username SNMP gets to see will not be my Kerberos principal name; it will be my SSH username, which is virtually never the same. Another possible approach is to invent the concept of a "TSM" namespace which is transport-independent. If we do this, there must be a mapping from names specific to a particular secure transport (again, NOT an underlying authentication method) to TSM names. This could be done by a table in TSM mapping (transport, transport-name) tuples to TSM names on the way up, and (transport, TSM-name) tuples to transport names on the way down. Or it could be done by a table in each secure transport model providing a bidirectional mapping between transport names and TSM names in the context of that transport. Basically, the question is, where do you want to deal with the issue that different secure transports may use different namespaces? We can deal with it in the secure transport model, or in TSM, or in VACM. The advantage to dealing with it further down is that the higher layers don't have to care about it in the case where there aren't multiple distinct namespaces (either because only one secure transport is used or because multiple transports are used that export the same names for all the names you care about). The advantage to dealing with it further up is that the lower levels don't have to do something special when the names _are_ different, and that you don't have a situation where a new transport appears with different names, some admin forgets (or doesn't know) to turn it off, and now there are clients who can get access to his system that they're not supposed to have. > 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. I think it does, and that therefore the "tags" must be standardized. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 29 03:39:19 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446F83A6B5C; Tue, 29 Jul 2008 03:39:19 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581A43A69B8 for ; Tue, 29 Jul 2008 03:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 AIa1NkpDVfTm for ; Tue, 29 Jul 2008 03:39:17 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 43F923A6B5C for ; Tue, 29 Jul 2008 03:39:17 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 3870E98376 for ; Tue, 29 Jul 2008 03:39:29 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 739B0399B93 for ; Tue, 29 Jul 2008 03:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :subject:date:message-id:mime-version:content-type; s=wesmail; bh=gFh87kE1e3JZu3/2FMiUCabPKYI=; b=Y6nSho2qFNhOTX3FuKNXGYulz5wF pdRC/OaCNc1b8Z7/q77BPHvnjDx5ZEGKURNEMJQgZ64Ute5p+lV15o/XRJ1zaTa7 BOD3p98TcFKetGsk7p2uHum8Y5ABjw6gzXAPOMVAH7/jermwv477XA9yHgLLBqFk AnSNvD8eq1zg4zQ= Received: by wes.hardakers.net (Postfix, from userid 274) id 82446399B9C; Tue, 29 Jul 2008 03:37:33 -0700 (PDT) From: Wes Hardaker To: ISMS WG Organization: Sparta Date: Tue, 29 Jul 2008 03:37:32 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I *think* that there is almost agreement on the following as a solution, based on discussions on the list and in the hallways. I think this is a reasonable compromise on most sides (it's not the solution I myself would pick, but I'm willing to accept it). It combines elements from multiple people and satisfies some of the issues some folks have. None of the elements are new, just combined. Points: * Defaults to no-configuration necessary for the easiest use case ** (IE, SSH user "david" will end up at the VACM as "david" unless the operator dictates otherwise). * Doesn't require a complex management scheme ** Uses a single scalar for configuration. It's not as flexible as some (including myself) may like, but it achieves the needed goal. * Allows separation of TM protocols if needed by an operator. * Assumes this is needed, which I'm not sure consensus has been reached on, but I think it's close. * Puts the prefixing requirement in the TM instead of the TSM so the TSM can be TM agnostic (providing more architectural separation). * Insanely simple to implement. Searching for a mandatory : passed up by the lower level transport and stripping it is very little code and should be very fast. Proposal Summary: In the TM document: "Documents defining a new TM implementation MUST define a security name prefix that will be pre-pended to all passed securityNames. This prefix MUST be from 1-4 securityName compatible octets followed by a ':' (ASCII 0x3a) character." In the TSM document: Add the following object (or similar) to the MIB: tsmStripSecurityNamePrefix OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates whether the transport modules string prefix will be removed before being passing the securityName to the message processing model. If set to true, the string prefix will be removed. If set to false, the string prefix will be left in place in front of the securityName passed up from the transport." DEFVAL { true } ::= { FILL } (sorry David, I forgot the object name you wanted but I'll leave it to you to propose the scalar name you wished) Change bullet 4 in section 5.2 to read: 4) Set securityName to the value of tmSecurityName from the cache referenced by tmStateReference. If the tsmStripSecurityNamePrefix object indicates that the TM prefix should be removed, remove everything up to and including the first ':' (ASCII 0x3a) character in the securityName value to be returned. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 29 03:53:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C24A3A6A39; Tue, 29 Jul 2008 03:53:36 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979A028C18A for ; Tue, 29 Jul 2008 03:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EENhAaacpQ2k for ; Tue, 29 Jul 2008 03:53:34 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id B57BB3A6A39 for ; Tue, 29 Jul 2008 03:53:34 -0700 (PDT) Received: from dhcp-130-129-19-120.meeting.ietf.org ([130.129.19.120]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6TArddN009087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 06:53:42 -0400 (EDT) Date: Tue, 29 Jul 2008 11:53:39 +0100 From: Jeffrey Hutzelman To: Wes Hardaker , ISMS WG Message-ID: In-Reply-To: <200807291039.m6TAdZkl007611@raisinbran.srv.cs.cmu.edu> References: <200807291039.m6TAdZkl007611@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Tuesday, July 29, 2008 03:37:32 AM -0700 Wes Hardaker wrote: > > I *think* that there is almost agreement on the following as a solution, > based on discussions on the list and in the hallways. I think this is a > reasonable compromise on most sides (it's not the solution I myself > would pick, but I'm willing to accept it). It combines elements from > multiple people and satisfies some of the issues some folks have. None > of the elements are new, just combined. I think this is reasonable. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 29 05:57:00 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D209028C26D; Tue, 29 Jul 2008 05:57:00 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F29528C1DD for ; Tue, 29 Jul 2008 05:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 E4Q1KEh9nLQj for ; Tue, 29 Jul 2008 05:56:59 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 1B6AE3A69D6 for ; Tue, 29 Jul 2008 05:56:59 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA01.westchester.pa.mail.comcast.net with comcast id vmG91Z0090vyq2s51owyWw; Tue, 29 Jul 2008 12:56:58 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA05.westchester.pa.mail.comcast.net with comcast id voxA1Z00124Kx1C3RoxAoV; Tue, 29 Jul 2008 12:57:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=biw4r1euT72XLCw_-3oA:9 a=wyz0jzVOg7CUq-swbKQA:9 a=MU0NPaGNOfTJPhjZ8S8l6meo2y4A:4 a=QMgMR9M9BAsA:10 From: "David B. Nelson" To: "'ISMS WG'" References: Date: Tue, 29 Jul 2008 08:57:10 -0400 Message-ID: <02e801c8f17a$9d89b150$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjxZ2K0ioMtq//6QFehRh8nAXEEPAAEns5A Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman writes... > It is a design feature of ISMS that we delegate to SSH the entire problem > of mapping names coming from potentially disparate authentication > namespaces into a common namespace which is provided to us. This is a > feature because SSH has to (and does) solve it anyway. > > If we extend this approach to every future secure transport mapping, such > that all such mappings can be expected to deal with any differences or > false similarities between names used by their authentication mechanisms, > then we are left only with the problem of dealing with differences and/or > false similarities between names provided us by different possible secure > transports. Well, that's very nice and convenient. I'm unaware of the document that specifies this "identity disambiguation" behavior of SSH authentication and that of other secure transports. Would you please give me a pointer? Thanks! Wes Hardaker writes... > I *think* that there is almost agreement on the following as a solution, > based on discussions on the list and in the hallways. I think this is a > reasonable compromise on most sides (it's not the solution I myself > would pick, but I'm willing to accept it). It combines elements from > multiple people and satisfies some of the issues some folks have. None > of the elements are new, just combined. Assuming that the behavior Jeff describes, above, is present (sorry to be a Doubting Thomas), it seems reasonable to me, too. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 29 06:17:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7230628C1AC; Tue, 29 Jul 2008 06:17:06 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BDA28C16A for ; Tue, 29 Jul 2008 06:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 ucrzvIpLuLAI for ; Tue, 29 Jul 2008 06:17:04 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 1A9843A69F9 for ; Tue, 29 Jul 2008 06:17:04 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA10.westchester.pa.mail.comcast.net with comcast id vnfu1Z00Q1HzFnQ5ApHGia; Tue, 29 Jul 2008 13:17:16 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA14.westchester.pa.mail.comcast.net with comcast id vpHF1Z00924Kx1C3apHFK6; Tue, 29 Jul 2008 13:17:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=cxfMDe7H6nIj-MA9Z6AA:9 a=0gDSDfKfAwOyewGUIGcA:9 a=f7ZK1NW1Kw67U66DG8vGLQiOW1gA:4 a=5FtdkfQUxfIA:10 From: "David B. Nelson" To: "'ISMS WG'" References: Date: Tue, 29 Jul 2008 09:17:16 -0400 Message-ID: <030101c8f17d$6c0b3920$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjxZ2K0ioMtq//6QFehRh8nAXEEPAAFbVMA Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker writes... > In the TM document: > "Documents defining a new TM implementation MUST define a security > name prefix that will be pre-pended to all passed securityNames. > This prefix MUST be from 1-4 securityName compatible octets > followed by a ':' (ASCII 0x3a) character." Will there be an IANA registry for this 1 to 4 character code? Or will we allow implementers to each make up their own set of abbreviations? I think an IANA registry is required, for purposes of interoperability. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 29 06:36:46 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7595128C2E4; Tue, 29 Jul 2008 06:36:46 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA8D28C2D3 for ; Tue, 29 Jul 2008 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8THNNuYNZfmR for ; Tue, 29 Jul 2008 06:36:44 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 1821328C2DC for ; Tue, 29 Jul 2008 06:36:44 -0700 (PDT) Received: from dhcp-130-129-19-120.meeting.ietf.org ([130.129.19.120]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m6TDaooJ013467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2008 09:36:51 -0400 (EDT) Date: Tue, 29 Jul 2008 14:36:50 +0100 From: Jeffrey Hutzelman To: "David B. Nelson" , "'ISMS WG'" Message-ID: <6349872EADC26618CBA90324@atlantis.pc.cs.cmu.edu> In-Reply-To: <200807291257.m6TCvEZ3010806@grapenut.srv.cs.cmu.edu> References: <200807291257.m6TCvEZ3010806@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Tuesday, July 29, 2008 08:57:10 AM -0400 "David B. Nelson" wrote: > Jeffrey Hutzelman writes... > >> It is a design feature of ISMS that we delegate to SSH the entire problem >> of mapping names coming from potentially disparate authentication >> namespaces into a common namespace which is provided to us. This is a >> feature because SSH has to (and does) solve it anyway. >> >> If we extend this approach to every future secure transport mapping, such >> that all such mappings can be expected to deal with any differences or >> false similarities between names used by their authentication mechanisms, >> then we are left only with the problem of dealing with differences and/or >> false similarities between names provided us by different possible secure >> transports. > > Well, that's very nice and convenient. I'm unaware of the document that > specifies this "identity disambiguation" behavior of SSH authentication > and that of other secure transports. Would you please give me a pointer? I think perhaps you misinterpreted what I said. I said that SSH solves the problem, and it does. This is a basic part of the way SSH user authentication works. Particularly, SSH does not try to map names used by a particular authentication mechanism onto SSH usernames. Instead, a client which is trying to authenticate must indicate what SSH username it wants, and the SSH server makes an authorization decision as to whether the client is allowed to use that username. The details of how that decision is made are mostly up to the particular userauth method used (and, to a large extent, up to the implementation and to local policy). So, the only way you can have two different clients with the same username is if two sets of credentials are authorized to use the same username. Those could be different credentials for the same userauth method, or for different methods. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 29 07:43:05 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2903A6A4F; Tue, 29 Jul 2008 07:43:05 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3193D3A6A4F for ; Tue, 29 Jul 2008 07:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.183, 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 feqYZ3T6Gu-t for ; Tue, 29 Jul 2008 07:43:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0C40B3A6927 for ; Tue, 29 Jul 2008 07:43:04 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3767EC0021; Tue, 29 Jul 2008 16:43:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sv6Nq1ZPDMSw; Tue, 29 Jul 2008 16:43:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20861C0040; Tue, 29 Jul 2008 16:43:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D17F567A835; Tue, 29 Jul 2008 16:43:08 +0200 (CEST) Date: Tue, 29 Jul 2008 16:43:08 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080729144308.GC11405@elstar.local> Mail-Followup-To: Wes Hardaker , ISMS WG References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ISMS WG Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Jul 29, 2008 at 03:37:32AM -0700, Wes Hardaker wrote: > Proposal Summary: > In the TM document: > "Documents defining a new TM implementation MUST define a security > name prefix that will be pre-pended to all passed securityNames. > This prefix MUST be from 1-4 securityName compatible octets > followed by a ':' (ASCII 0x3a) character." > > In the TSM document: > Add the following object (or similar) to the MIB: > > tsmStripSecurityNamePrefix OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object indicates whether the transport modules string > prefix will be removed before being passing the securityName > to the message processing model. If set to true, the string > prefix will be removed. If set to false, the string prefix > will be left in place in front of the securityName passed up > from the transport." > DEFVAL { true } > ::= { FILL } > > (sorry David, I forgot the object name you wanted but I'll leave it > to you to propose the scalar name you wished) > > Change bullet 4 in section 5.2 to read: > > 4) Set securityName to the value of tmSecurityName from the cache > referenced by tmStateReference. If the tsmStripSecurityNamePrefix > object indicates that the TM prefix should be removed, remove > everything up to and including the first ':' (ASCII 0x3a) > character in the securityName value to be returned. What happens if I send a notification? Is everything sane in this case? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jul 29 19:38:18 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CEE3A6B6B; Tue, 29 Jul 2008 19:38:18 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174AE3A6B6B for ; Tue, 29 Jul 2008 19:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 7J7iVA4K3y24 for ; Tue, 29 Jul 2008 19:38:17 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 305363A69EF for ; Tue, 29 Jul 2008 19:38:17 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA03.westchester.pa.mail.comcast.net with comcast id vn5W1Z0050EZKEL532eVYX; Wed, 30 Jul 2008 02:38:29 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA01.westchester.pa.mail.comcast.net with comcast id w2eU1Z00X24Kx1C3M2eVJo; Wed, 30 Jul 2008 02:38:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=QySEpqNzBBUHuEXwvzoA:9 a=3RNAwtX9d1ImdWXKlRAA:9 a=fwbaQJBv7H257sdNvctv9fDTqH4A:4 a=QMgMR9M9BAsA:10 From: "David B. Nelson" To: "'ISMS WG'" References: <200807291257.m6TCvEZ3010806@grapenut.srv.cs.cmu.edu> <6349872EADC26618CBA90324@atlantis.pc.cs.cmu.edu> Date: Tue, 29 Jul 2008 22:38:29 -0400 Message-ID: <03c401c8f1ed$5a9cfc80$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6349872EADC26618CBA90324@atlantis.pc.cs.cmu.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjxgCuetcjzre58RmCXpUW/70pTVQAbMTsw Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman writes... > I think perhaps you misinterpreted what I said. Well, that's entirely possible. > So, the only way you can have two different clients with the same > username is if two sets of credentials are authorized to use the > same username. Hmmm. I'll go off and re-read the SSH authentication method documents and see if I can reconcile this for myself. If not, I may be back. :-) _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 31 01:29:57 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D393A6971; Thu, 31 Jul 2008 01:29:57 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEDB3A689E for ; Thu, 31 Jul 2008 01:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 I-5HmOhALP5X for ; Thu, 31 Jul 2008 01:29:55 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 06C4F3A6855 for ; Thu, 31 Jul 2008 01:29:29 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 34C6F9840A; Thu, 31 Jul 2008 01:29:24 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 4D0FC399B9F; Wed, 30 Jul 2008 06:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=krcEz9TxCcaW7NfbK/sxOo8d0v0=; b=KuzK cWlj9ZEKZ1gnO/6frlCVRpbjSFnQGdjBVXnhCRumujUssALMzoDblGKIKLcgYysh fEm4ny3jSf5TfPf3sacRtJDW9d78MhwLllywEI4lEyyZXzsjtw43/0jNtk7O4kqk cEVGLyU85DxDGZKDdQujKFAVaPSzc2LyBeVMZM4= Received: by wes.hardakers.net (Postfix, from userid 274) id 445A7399BA0; Wed, 30 Jul 2008 06:59:28 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <030101c8f17d$6c0b3920$6401a8c0@NEWTON603> Date: Wed, 30 Jul 2008 06:59:28 -0700 In-Reply-To: <030101c8f17d$6c0b3920$6401a8c0@NEWTON603> (David B. Nelson's message of "Tue, 29 Jul 2008 09:17:16 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: 'ISMS WG' Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Tue, 29 Jul 2008 09:17:16 -0400, "David B. Nelson" said: DBN> Will there be an IANA registry for this 1 to 4 character code? Or DBN> will we allow implementers to each make up their own set of DBN> abbreviations? I think an IANA registry is required, for purposes DBN> of interoperability. I think that some of the other registrations options could be just fine too, but I think IANA is probably the best of that set of options. So yes, I agree, it'd require IANA text and action. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 31 01:29:58 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4543A69E4; Thu, 31 Jul 2008 01:29:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88323A6807 for ; Thu, 31 Jul 2008 01:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 tUKlry4VJ3zJ for ; Thu, 31 Jul 2008 01:29:56 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id DF5303A68DB for ; Thu, 31 Jul 2008 01:29:32 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 658E99845C; Thu, 31 Jul 2008 01:29:24 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 31EDE399B9E; Wed, 30 Jul 2008 06:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=mkNSiN4SsiFWRLlI/yW+b3Z3vOc=; b=OhD1 tpGM2SiKsC6RA6P88P+/X0IB3mHIWtZtFIZwx4jsHnXFSnuDMg+Oum26WrgWpa/l w8d4jjxkDhj6Z07Cn9EOKakwu8c7xinSnL7VwzrllEFHkzl/WIaFmuPuHdyMSl8P ACIpdsF+EMLztnAblP9tVtDVVFQCX8G2o0cVUCY= Received: by wes.hardakers.net (Postfix, from userid 274) id 19A21399B9F; Wed, 30 Jul 2008 06:58:41 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20080729144308.GC11405@elstar.local> Date: Wed, 30 Jul 2008 06:58:40 -0700 In-Reply-To: <20080729144308.GC11405@elstar.local> (Juergen Schoenwaelder's message of "Tue, 29 Jul 2008 16:43:08 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: ISMS WG Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Tue, 29 Jul 2008 16:43:08 +0200, Juergen Schoenwaelder said: JS> What happens if I send a notification? Is everything sane in this case? The remote side will still be tied to the securityName provided by (in this case) the notification originator if the scalar was set to true (strip the prefix). It does beg the question, though, is if the scalar is set to false then does the notification need to be set up (via the target-mib) with the securityName "ssh:juergen" or just "juergen". I can argue it either way and actually don't care too much as long as it's defined. Since the VACM authorization is functionally done *before* the agent tries to send the notification and it's using it's own data to do that, it would likely make sense to require the prefix to be set up properly already in both the target-mib and (obviously) the VACM tables. It will, however, require probably another sentence in text talking about stripping the prefix before opening a session where the securityName used for openSession() would be expected to be prefixed. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 31 01:39:32 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59003A6A13; Thu, 31 Jul 2008 01:39:32 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306E33A6A13 for ; Thu, 31 Jul 2008 01:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, 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 9wJCnMi5NL1v for ; Thu, 31 Jul 2008 01:39:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B9F5E3A69EB for ; Thu, 31 Jul 2008 01:39:29 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDC87C001D; Thu, 31 Jul 2008 10:39:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aWAThgqTcrP3; Thu, 31 Jul 2008 10:39:07 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54C8DC0049; Thu, 31 Jul 2008 10:39:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E7FA067D58B; Thu, 31 Jul 2008 10:39:05 +0200 (CEST) Date: Thu, 31 Jul 2008 10:39:05 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080731083905.GA16200@elstar.local> Mail-Followup-To: Wes Hardaker , ISMS WG References: <20080729144308.GC11405@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ISMS WG Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, Jul 30, 2008 at 06:58:40AM -0700, Wes Hardaker wrote: > >>>>> On Tue, 29 Jul 2008 16:43:08 +0200, Juergen Schoenwaelder said: > > JS> What happens if I send a notification? Is everything sane in this case? > > The remote side will still be tied to the securityName provided by (in > this case) the notification originator if the scalar was set to true > (strip the prefix). It does beg the question, though, is if the scalar > is set to false then does the notification need to be set up (via the > target-mib) with the securityName "ssh:juergen" or just "juergen". I > can argue it either way and actually don't care too much as long as it's > defined. If the prefix is dropped by TSM, then I think all the "higher" layers in the SNMP engine should never see/worry about the prefix. So it is TSM's job to put the prefix back in place again for outgoing notifications. There is however an issue here with length restrictions. If I setup a 30 byte security name, there is no space to squeeze in a prefix anymore and we have to drop the message. This might not be a show stopper as long as we have a proper error counter for this. > Since the VACM authorization is functionally done *before* the agent > tries to send the notification and it's using it's own data to do that, > it would likely make sense to require the prefix to be set up properly > already in both the target-mib and (obviously) the VACM tables. See above for an argument for a different position. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 31 02:41:31 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42F63A6B08; Thu, 31 Jul 2008 02:41:31 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E01C3A6A60 for ; Thu, 31 Jul 2008 02:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6] 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 pltRe085IKBH for ; Thu, 31 Jul 2008 02:41:29 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id C951E3A63D2 for ; Thu, 31 Jul 2008 02:41:29 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 9B736983C2; Thu, 31 Jul 2008 02:41:14 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 6E227399B93; Thu, 31 Jul 2008 02:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=yIPC2vicA0zW/dmyheCP0iJ3RS8=; b=IJpt UxzHq0ErJfUmIu0na2fwSgrHIwWg9KRtyRrigrOU1XzABfcBECfsFoXKtYWd/2Pp 6FEBpS9U7sdOlqiadoTzqW0dzstYNOPsRB3lsnag/O1EasGZaZw8RA3nZSM2+Q22 RFZWxGIEYgEsCcwUphUZLXQDB/p0HZ2QXPTIHYQ= Received: by wes.hardakers.net (Postfix, from userid 274) id 54FE2399B9C; Thu, 31 Jul 2008 02:41:13 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20080729144308.GC11405@elstar.local> <20080731083905.GA16200@elstar.local> Date: Thu, 31 Jul 2008 02:41:12 -0700 In-Reply-To: <20080731083905.GA16200@elstar.local> (Juergen Schoenwaelder's message of "Thu, 31 Jul 2008 10:39:05 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: ISMS WG Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Thu, 31 Jul 2008 10:39:05 +0200, Juergen Schoenwaelder said: JS> If the prefix is dropped by TSM, then I think all the "higher" layers JS> in the SNMP engine should never see/worry about the prefix. So it is JS> TSM's job to put the prefix back in place again for outgoing JS> notifications. Well, except it's not the lower layers that actually care. Really, the thing that cares the most is the VACM which is where we need it. The "agent" is the one that needs the prefixed name since it can check the VACM for ssh:juergen vs dtls:juergen when the scalar is set to false regardless of whether it's checking the authorization of a SET or a INFORM. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 31 02:46:27 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22603A6AE9; Thu, 31 Jul 2008 02:46:27 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34723A6807 for ; Thu, 31 Jul 2008 02:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6] 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 xRmLZgX-lLdM for ; Thu, 31 Jul 2008 02:46:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CF2BB3A6AE9 for ; Thu, 31 Jul 2008 02:46:25 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A574C0047; Thu, 31 Jul 2008 11:46:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uwGMPS5TJuA9; Thu, 31 Jul 2008 11:46:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 561AFC0052; Thu, 31 Jul 2008 11:46:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2BE3267EDAF; Thu, 31 Jul 2008 11:46:30 +0200 (CEST) Date: Thu, 31 Jul 2008 11:46:30 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080731094630.GB23731@elstar.local> Mail-Followup-To: Wes Hardaker , ISMS WG References: <20080729144308.GC11405@elstar.local> <20080731083905.GA16200@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ISMS WG Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Thu, Jul 31, 2008 at 02:41:12AM -0700, Wes Hardaker wrote: > >>>>> On Thu, 31 Jul 2008 10:39:05 +0200, Juergen Schoenwaelder said: > > JS> If the prefix is dropped by TSM, then I think all the "higher" layers > JS> in the SNMP engine should never see/worry about the prefix. So it is > JS> TSM's job to put the prefix back in place again for outgoing > JS> notifications. > > Well, except it's not the lower layers that actually care. Really, the > thing that cares the most is the VACM which is where we need it. The > "agent" is the one that needs the prefixed name since it can check the > VACM for ssh:juergen vs dtls:juergen when the scalar is set to false > regardless of whether it's checking the authorization of a SET or a INFORM. But if I turn the 'drop magic prefixes' button on in TSM, I likely do this because I do not want to distinguish between dtls:schoenw and tls:schoenw, that is, I do not want to deal with this distinction in VACM. So in this case, I would expect that TSM has to fill in the right prefix, no? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jul 31 03:00:37 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCCE3A68E6; Thu, 31 Jul 2008 03:00:37 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7F43A6807 for ; Thu, 31 Jul 2008 03:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.238 X-Spam-Level: X-Spam-Status: No, score=-1.238 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_37=0.6, J_CHICKENPOX_47=0.6] 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 V0LPqjFj-47h for ; Thu, 31 Jul 2008 03:00:36 -0700 (PDT) Received: from mail.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 02C713A6885 for ; Thu, 31 Jul 2008 03:00:36 -0700 (PDT) Received: from wes.hardakers.net (dawn.hardakers.net [127.0.0.1]) by mail.hardakers.net (Postfix) with ESMTP id 4312D983E7; Thu, 31 Jul 2008 03:00:39 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 68D96399B93; Thu, 31 Jul 2008 03:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=4kLNw4NMq/oFNkLDFwaR4SfB2Nk=; b=X31y R3/qyj4unCYqVDw3xiCJRD5s3zvrNQrHq1iX6WFCvFgz0GZDUcfY66VvtQ6VRitI 1dGDUEPjf944X4ncfQIoVHt+KJHAbCMeuIdJ6bcgkGO1/BlsTzsUjfOKdzBzcUwF c0qthX+fS1xjb5D+g/CRfX7J6eUZG5560MNBsAQ= Received: by wes.hardakers.net (Postfix, from userid 274) id 42ACA399B9C; Thu, 31 Jul 2008 03:00:38 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20080729144308.GC11405@elstar.local> <20080731083905.GA16200@elstar.local> <20080731094630.GB23731@elstar.local> Date: Thu, 31 Jul 2008 03:00:38 -0700 In-Reply-To: <20080731094630.GB23731@elstar.local> (Juergen Schoenwaelder's message of "Thu, 31 Jul 2008 11:46:30 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: ISMS WG Subject: Re: [Isms] current naming agreement X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Thu, 31 Jul 2008 11:46:30 +0200, Juergen Schoenwaelder said: JS> But if I turn the 'drop magic prefixes' button on in TSM, I likely do JS> this because I do not want to distinguish between dtls:schoenw and JS> tls:schoenw, that is, I do not want to deal with this distinction in JS> VACM. So in this case, I would expect that TSM has to fill in the JS> right prefix, no? Yes, I guess that would make sense though I'm not sure who the consumer is at this point. I guess the TM will need to strip it from above as well (always) before using it on the wire, but other than that it has no impact on any other module, right? -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms